Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
alphaonedev avatar

Linux Systemd

  • 61 installs
  • 6 repo stars
  • Updated March 13, 2026
  • alphaonedev/openclaw-graph

linux-systemd is a Claude skill that teaches an agent to manage systemd services on Linux via unit files, systemctl, journalctl, cgroup integration, and socket activation.

About

This skill is a reference for managing systemd on Linux. It documents writing unit files, controlling services with systemctl, reading logs with journalctl, applying cgroup limits inside units, and setting up socket activation. A developer uses it to run a daemon or long-lived binary as a managed systemd service and monitor it.

  • Reference card for managing systemd services on Linux
  • Covers unit files, systemctl, journalctl, cgroup integration, and socket activation
  • Includes unit-file templates and daemon-reload/start/restart workflows

Linux Systemd by the numbers

  • 61 all-time installs (skills.sh)
  • Ranked #682 of 1,039 Cloud & Infrastructure skills by installs in the Skillselion catalog
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
At a glance

linux-systemd capabilities & compatibility

Free; local root shell, no API keys required

Capabilities
service management · log management · socket activation · resource limits
Use cases
devops
Platforms
Linux
Pricing
Free
From the docs

What linux-systemd says it does

This skill provides tools for managing systemd on Linux, focusing on service units, system control, logging, and integration features like cgroups and socket activation
SKILL.md
Query logs with journalctl for real-time or historical output from specific units.
SKILL.md
Avoid it on non-systemd systems like BSD or custom init setups.
SKILL.md
npx skills add https://github.com/alphaonedev/openclaw-graph --skill linux-systemd

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs61
repo stars6
Last updatedMarch 13, 2026
Repositoryalphaonedev/openclaw-graph

What it does

Reference for an agent to run and manage Linux services with systemd: unit files, systemctl, journalctl, and cgroup limits.

Who is it for?

Automating Linux service operations: starting/stopping daemons, reading logs, and applying cgroup limits

Skip if: Non-systemd systems like BSD or custom init setups

When should I use this skill?

You need an agent to write a unit file, control a service with systemctl, tail journalctl, or set up socket activation

By the numbers

  • cgroup example sets CPUQuota=50% in a unit file
  • socket activation example uses ListenStream=12345

Files

SKILL.mdMarkdownGitHub ↗

linux-systemd

Purpose

This skill provides tools for managing systemd on Linux, focusing on service units, system control, logging, and integration features like cgroups and socket activation, specifically for OpenClaw service management.

When to Use

Use this skill when you need to automate Linux service operations, such as starting/stopping daemons, monitoring logs, or optimizing resource usage with cgroups. Apply it in scripts for system administration, container orchestration, or when integrating OpenClaw as a systemd service. Avoid it on non-systemd systems like BSD or custom init setups.

Key Capabilities

  • Manage systemd unit files for services, sockets, and timers, including editing files in /etc/systemd/system/.
  • Control services via systemctl commands, such as starting, stopping, and restarting units.
  • Query logs with journalctl for real-time or historical output from specific units.
  • Integrate cgroups for resource limits, e.g., CPU/memory constraints on services.
  • Enable socket activation for on-demand service starts, reducing resource overhead.
  • Handle OpenClaw as a systemd service by creating a unit file with ExecStart pointing to the OpenClaw binary.

Usage Patterns

Always run commands with elevated privileges using sudo or as root. In scripts, use subprocess calls in Python or shell exec in Bash to invoke systemctl/journalctl. For unit file creation, edit files directly or use systemd-analyze for validation. When integrating with OpenClaw, ensure the service unit references the correct binary path and environment variables. Structure patterns as: detect service state first, then perform actions, and log outputs. For cgroups, specify limits in the unit file's [Service] section before reloading systemd.

Common Commands/API

Use systemctl for service management: e.g., systemctl start <unit> to start a service. For logs, run journalctl -u <unit> -f to follow output. To restart, use systemctl restart <unit> --no-block for non-blocking operation. For cgroups, inspect with systemctl status <unit> | grep CGroup or set via unit file. Socket activation setup: add Sockets= in the unit file and use systemctl start <socket-unit>. Code snippet in Bash:

#!/bin/bash
systemctl stop my-service
systemctl start my-service
echo "Service restarted"

In Python, use:

import subprocess
subprocess.run(['systemctl', 'status', 'my-service'])

For OpenClaw service, create a unit file like:

[Unit]
Description=OpenClaw Service
[Service]
ExecStart=/usr/bin/openclaw --config /etc/openclaw/config.json

Integration Notes

To integrate cgroups, add lines like CPUQuota=50% in the [Service] section of a unit file, then run systemctl daemon-reload and restart the unit. For socket activation, define a .socket unit file (e.g., ListenStream=12345) and link it to your service unit. When managing OpenClaw as a service, set environment variables in the unit file, e.g., Environment="OPENCLAW_API_KEY=$SERVICE_API_KEY", and ensure $SERVICE_API_KEY is set via export in your shell or systemd environment files. Reload systemd with systemctl daemon-reload after changes. Avoid conflicts by checking for existing units with systemctl list-units --type=service.

Error Handling

Always check command exit codes; for example, in Bash, use if systemctl start <unit>; then echo "Success"; else echo "Failed: $?"; fi. In Python, wrap subprocess calls in try-except blocks: try: subprocess.run([...], check=True) except subprocess.CalledProcessError as e: print(f"Error: {e.returncode}"). Common errors include "Failed to start unit" (check permissions or dependencies) or "Unit not found" (verify unit name with systemctl list-units). For journalctl, handle no logs with journalctl -u <unit> --since "1 hour ago" and parse output for errors. If cgroups fail, use systemctl status <unit> to debug limits, and ensure kernel support with cat /proc/cgroups.

Concrete Usage Examples

Example 1: Start and monitor an OpenClaw service. First, create a unit file at /etc/systemd/system/openclaw.service with contents:

[Unit]
Description=OpenClaw Daemon
[Service]
ExecStart=/usr/bin/openclaw

Then, run: systemctl daemon-reload; systemctl start openclaw; journalctl -u openclaw -f to start and tail logs.

Example 2: Restart a service with cgroup limits. Edit the unit file to include [Service] CPUQuota=30%, then execute: systemctl daemon-reload; systemctl restart my-service. Verify with systemctl status my-service | grep CGroup to ensure CPU limits are applied.

Graph Relationships

  • Connected to: linux cluster (e.g., shares dependencies with other linux skills like file management or process control).
  • Related via tags: systemd (direct link), services (e.g., to container or orchestration skills), linux (broad cluster ties), units (links to resource management skills).
  • Integration points: cgroup (connects to performance monitoring tools), socket activation (relates to networking skills).

Related skills

FAQ

How do you tail logs for a systemd service?

Run journalctl -u <unit> -f to follow the unit's output in real time.

How do you apply a CPU limit to a service?

Add a line like CPUQuota=50% under the [Service] section of the unit file, run systemctl daemon-reload, then restart the unit.

Cloud & Infrastructureinframonitoring

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.