
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)
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
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
Query logs with journalctl for real-time or historical output from specific units.
Avoid it on non-systemd systems like BSD or custom init setups.
npx skills add https://github.com/alphaonedev/openclaw-graph --skill linux-systemdAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 61 |
|---|---|
| repo stars | ★ 6 |
| Last updated | March 13, 2026 |
| Repository | alphaonedev/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
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.jsonIntegration 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/openclawThen, 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.