Back to lessons

Linux Survival Basics

Compare Failure Output With the Effective Unit

systemctl status names a failed startup step, but you need to connect that symptom to the effective unit and drop-in configuration.

Command

systemctl status app-worker --no-pager --lines=50 && systemctl cat app-worker

What changed

Nothing changes. The commands print failure evidence followed by the unit fragments systemd loaded.

Danger

safe

When to use it

Use when status mentions USER, CHDIR, EXEC, environment files, or a drop-in and you need the config beside the failure evidence.

When not to use it

Do not edit the service until you know whether the main unit or a drop-in owns the setting you plan to change.

Undo or recovery

No undo needed because the commands are read-only.

Expected output

A failed status page followed by the main unit file and drop-in override that changes the service user.

demo script

Disposable terminal steps

  1. systemctl status app-worker --no-pager --lines=50
  2. systemctl cat app-worker

simulated output

What it looks like

disposable vessel
::fixture-ready::
$ systemctl status app-worker --no-pager --lines=50
● app-worker.service - Background job worker
     Loaded: loaded (/etc/systemd/system/app-worker.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/app-worker.service.d
             └─override.conf
     Active: failed (Result: exit-code) since Thu 2026-06-25 14:22:17 CDT; 4min ago
   Duration: 1.243s
    Process: 2144 ExecStart=/srv/app/bin/worker --queue default (code=exited, status=217/USER)
   Main PID: 2144 (code=exited, status=217/USER)
        CPU: 38ms

Jun 25 14:22:17 vps systemd[1]: Started app-worker.service - Background job worker.
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed to determine user credentials: No such process
Jun 25 14:22:17 vps systemd[2144]: app-worker.service: Failed at step USER spawning /srv/app/bin/worker: No such process
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Main process exited, code=exited, status=217/USER
Jun 25 14:22:17 vps systemd[1]: app-worker.service: Failed with result 'exit-code'.
::exit-code::0
$ systemctl cat app-worker
# /etc/systemd/system/app-worker.service
[Unit]
Description=Background job worker
After=network-online.target redis.service
Wants=network-online.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/srv/app/current
EnvironmentFile=/etc/app/worker.env
ExecStart=/srv/app/bin/worker --queue default
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/app-worker.service.d/override.conf
[Service]
User=missing-appuser
Environment=QUEUE=critical
::exit-code::0

YouTube Short

Put failure next to config.

When status names a failed step, print the effective unit right after it. The override often explains the symptom.

LinkedIn hook

Put the failed step next to the unit config that created it.

Question: Do you compare systemd status output with the effective unit before editing overrides?

experiments

A/B tests to run

Metric: average_view_duration

A: Put failure next to config.

B: The override may explain the failure.