systemctl status: Check a Service on a CI Runner
systemctl status <unit> prints a service’s active state, main PID, and a tail of its journal.
When a self-hosted runner depends on Docker, a database, or the runner agent itself, systemctl status is the first check: is the unit running, and if not, why did it stop.
What it does
systemctl status queries systemd for a unit and prints its load state, active state (active, inactive, failed), the main PID and cgroup, plus the last ~10 journal lines. The exit code is 0 when active and 3 when inactive or failed, which makes it scriptable.
Common usage
systemctl status docker
systemctl status actions.runner.myorg-repo.runner.service
systemctl is-active docker # prints "active" / "inactive", exit code reflects state
systemctl is-enabled docker # whether it starts at bootOptions
| Flag / subcommand | What it does |
|---|---|
| status <unit> | Show full state plus recent log lines |
| is-active <unit> | Print active/inactive, exit 0 only if active |
| is-failed <unit> | Exit 0 if the unit is in the failed state |
| --no-pager | Do not pipe output through less (needed in CI) |
| -l / --full | Do not truncate long log lines |
| --user | Operate on the per-user systemd instance |
In CI
Always add --no-pager; without it systemctl opens less and the step hangs with no output until the job times out. To assert a dependency is up before tests, use systemctl is-active --quiet docker || sudo systemctl start docker.
Common errors in CI
"Failed to connect to bus: No such file or directory" means there is no systemd (a container, not a VM); use the service binary directly instead. "Unit docker.service could not be found." means the unit name is wrong or the package is not installed. "Access denied" on start/stop needs sudo or a polkit rule.