How to Actually Read `systemctl status` Output

You run systemctl status nginx and get a wall of text. Most of it looks like noise. But it’s all signal if you know how to read it.

Let’s decode every field in systemctl status output.

A Sample Output

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/etc/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2025-04-16 10:23:45 UTC; 2 days ago
       Docs: man:nginx(8)
    Process: 1234 ExecStart=/usr/sbin/nginx -g daemon off; (code=exited, status=0/SUCCESS)
   Main PID: 1235 (nginx)
      Tasks: 5
     Memory: 12.5M
        CPU: 2h 14m 23.120s
     CGroup: /system.slice/nginx.service
             ├─1235 nginx: master process /usr/sbin/nginx -g daemon off;
             ├─1236 nginx: worker process
             └─1237 nginx: worker process

     Apr 16 10:23:45 server nginx[1235]: 2025/04/16 10:23:45 [notice] 1235#1235:
     Apr 16 10:23:46 server nginx[1236]: Connection established

Let’s break this down line by line.

The Header

● nginx.service - A high performance web server and a reverse proxy server

The ● bullet shows the status visually:

• ● (filled) = running
• ○ (empty) = stopped
• ⊘ (crossed) = failed

The service name is nginx.service. The description comes from the Description= field in the unit file.

Loaded

Loaded: loaded (/etc/systemd/system/nginx.service; enabled; vendor preset: enabled)

Loaded state:

• loaded — Unit file found and parsed
• not-found — Unit file doesn’t exist
• bad-setting — Unit file has syntax errors
• error — Other parsing error

Enabled/Disabled:

• enabled — Service starts at boot
• disabled — Service doesn’t start at boot
• static — Service is dependency of another unit, can’t be directly enabled/disabled
• masked — Service can’t be started (intentionally disabled)

Vendor preset:

• The default state from the distribution (enabled or disabled)

In this example: The service is loaded and enabled, meaning it starts automatically on boot.

Active

Active: active (running) since Wed 2025-04-16 10:23:45 UTC; 2 days ago

Active state:

• active (running) — Service is running
• active (exited) — Service ran successfully and exited (one-shot service)
• active (waiting) — Service is waiting for something
• inactive (dead) — Service is stopped
• inactive (waiting) — Service is waiting to be started
• failed — Service crashed or reached an error state

The timestamp shows when the state changed.

Failed service example:

Active: failed (Result: exit-code) since Wed 2025-04-16 10:23:45 UTC; 2 days ago

If it’s failed, check:

• exit-code — Process exited with nonzero status
• signal — Process was killed by a signal (SIGTERM, SIGKILL, etc.)
• core-dump — Process dumped core (crashed hard)
• timeout — Service took too long to start or stop

Process and Main PID

Process: 1234 ExecStart=/usr/sbin/nginx -g daemon off; (code=exited, status=0/SUCCESS)
Main PID: 1235 (nginx)

Process line: Shows the result of the last ExecStart command (how the service started).

• code=exited, status=0 — Process exited with status 0 (success)
• code=exited, status=1 — Exited with status 1 (error)
• code=killed, signal=15 — Killed with SIGTERM

Main PID: The process ID of the main process. If this PID dies, systemd restarts the service (if configured).

Mismatch? If Main PID is gone but the service says “running”, something’s wrong. The service might have crashed but systemd hasn’t noticed yet.

Tasks, Memory, CPU

Tasks: 5
Memory: 12.5M
CPU: 2h 14m 23.120s

• Tasks — Number of processes in this service’s cgroup
• Memory — RSS memory usage (excluding page cache)
• CPU — Total CPU time consumed (user + system)

High CPU and low memory? Infinite loop or busy-waiting. High memory? Memory leak.

CGroup

CGroup: /system.slice/nginx.service
        ├─1235 nginx: master process /usr/sbin/nginx -g daemon off;
        ├─1236 nginx: worker process
        └─1237 nginx: worker process

This is the process tree. Shows all processes belonging to the service.

Each line shows:

• PID
• Process name and arguments

If you see processes here that shouldn’t be, something spawned child processes that didn’t die.

If you see no processes but the service says “running”, the main process just died.

Recent Logs

Apr 16 10:23:45 server nginx[1235]: 2025/04/16 10:23:45 [notice] 1235#1235:
Apr 16 10:23:46 server nginx[1236]: Connection established

The last few lines from the journal. Useful for spotting recent errors.

If logs are missing, check:

• Did journald start after the service?
• Is the service outputting to syslog vs its own handler?

See full logs with:

journalctl -u nginx

Putting It Together: Troubleshooting Examples

Service is failed

Active: failed (Result: exit-code) since Wed 2025-04-16 10:23:45 UTC; 5 minutes ago

Action: Check the log section and recent journal entries.

journalctl -u nginx -n 50

Service is running but Main PID is gone

Active: active (running) since Wed 2025-04-16 10:23:45 UTC; 2 days ago
Main PID: 1235 (nginx) [WRONG, PID doesn't exist]

The service crashed but systemd hasn’t reloaded the status yet, or the service doesn’t restart on failure.

Action:

systemctl restart nginx
journalctl -u nginx -f  # Follow live

Memory usage is climbing

Memory: 512M  # Or whatever is huge

Action: Check if there’s a memory leak.

journalctl -u nginx -p warning  # Check for warnings
systemctl restart nginx          # Restart and monitor

CPU is pegged at 100%

CPU: 500h 20m (abnormally high)

The service has been running 500 hours and used 500 hours of CPU? That’s 100% utilization since it started.

Action:

top -p <PID>  # See what's eating CPU

Service is disabled but running

Loaded: loaded (...; disabled; ...)
Active: active (running) since ...

This means the service was manually started, but won’t restart on reboot.

Action: Decide if it should be enabled:

systemctl enable nginx  # Enable at boot
systemctl disable nginx # Don't start at boot

Service takes forever to stop

Active: failed (Result: timeout) since Wed 2025-04-16 10:23:45 UTC; 1 minute ago

The service didn’t stop within TimeoutStopSec (default 30s).

Either:

1. The service is hanging on shutdown
2. The timeout is too short
3. A child process isn’t shutting down cleanly

Action:

systemctl kill nginx        # Force kill
systemctl status nginx      # Check status
journalctl -u nginx -n 20  # See what happened

The Full Context Command

To get complete information:

systemctl status nginx -l --no-pager
# -l = full output (don't truncate)
# --no-pager = all at once

Then follow the live journal:

journalctl -u nginx -f

Reading a One-Shot Service

One-shot services run once and exit:

Active: active (exited) since Wed 2025-04-16 10:23:45 UTC; 2 days ago

This is normal. “Exited” doesn’t mean failed, it means the service did its job and stopped.

If it has RemainAfterExit=yes in the unit file, it stays “active” even after exiting. Otherwise, it goes to “inactive (dead)” after a few seconds.

The Quick Diagnosis

When something’s broken, run these in order:

# 1. What's the status?
systemctl status service-name

# 2. See the recent logs
journalctl -u service-name -n 50 --no-pager

# 3. Follow live
journalctl -u service-name -f

Most problems are visible in the status and logs. You’ll find your answer there.

Systemctl status is one of the most powerful diagnostic tools in Linux. Learn to read it and you’ll debug services in seconds instead of minutes.