Quickly inspect whether a daemon runs and find the reason when it does not. 16.11.2025 | reading time: 3 min Want a fast way to know if a service is running and why it might have stopped? Use the command-line tool systemctl status to query systemd for the current state, recent logs, the main PID and more; it is the first stop when a daemon misbehaves. Inspect a real service Run the command and read the short report; here is a practical example showing command and typical output: ```bash $ systemctl status nginx.service ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2025-11-10 09:12:34 UTC; 2h 3min ago Main PID: 2145 (nginx) Tasks: 3 (limit: 2319) Memory: 7.8M CGroup: /system.slice/nginx.service ├─2145 nginx: master process /usr/sbin/nginx └─2146 nginx: worker process Nov 10 09:12:34 host systemd[1]: Started A high performance web server and a reverse proxy server. Nov 10 10:45:01 host nginx[2146]: 2025/11/10 10:45:01 [error] 2146#0: *123 connect() failed (111: Connection refused) ``` Decode the fields quickly Look for three immediate clues: the Loaded line shows whether the unit file is present and enabled, Active reveals running, exited or failed state, and Main PID identifies the process to inspect; use the little snippet of recent log lines at the bottom to find the immediate cause and the CGroup to see related processes. Options that speed troubleshooting When you need more or less context, add parameters: use `-n` to show a specific number of log lines, `-l` to avoid truncation, `--no-pager` to pipe to other tools, or check `systemctl is-active` and `systemctl is-enabled` for machine-readable answers; when a service failed, restart it with `systemctl restart` and then re-run status to confirm. Follow logs and dig deeper If status shows errors, inspect full logs with journalctl for that unit, for example `journalctl -u nginx.service -b` to see logs since boot; pair that with process inspection tools and strace or lsof on the Main PID when you need to trace system calls or open files. Use cases beyond a single check Use systemctl status in scripts to gate actions, include it in monitoring playbooks to capture service health snapshots, run it during boot troubleshooting to find units blocking startup, and combine it with enable/disable to control persistence across reboots. Wider tooling to know systemctl focuses on systemd units, but troubleshooting often requires journalctl for logs, ps or top for live process details, and networking tools to verify sockets and connections; learn to move between these quickly. What comes next You can now inspect services, read the most relevant lines of their logs and take corrective action; keep practicing by reproducing failures in a safe VM and build quick checklists for common services, then consider formal study to deepen your skills and validate them with certifications like CompTIA Linux+ or LPIC-1 with intensive exam preparation at bitsandbytes.academy. Join Bits & Bytes Academy First class LINUX exam preparation. troubleshooting processes boot-process utilities infrastructure
