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
systemctl status app-worker --no-pager --lines=50systemctl cat app-worker
simulated output
What it looks like
::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.