Linux Survival Basics
Inspect the Unit File and Drop-ins Together
A service definition looks correct in the main unit, but a drop-in override may be changing the user, environment, or command.
Command
systemctl cat app-worker
What changed
Nothing changes. systemctl prints the effective unit file fragments and drop-ins in order.
Danger
safe
When to use it
Use when status mentions a drop-in, a service changed after deployment, or the failure points at user, path, environment, or ExecStart.
When not to use it
Do not edit from memory after reading this; make a deliberate unit or drop-in change and reload systemd when applying a fix.
Undo or recovery
No undo needed because the command is read-only.
Expected output
The main service unit followed by drop-in override contents.
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
Check drop-ins before editing.
If status shows a drop-in, inspect the unit and override together. The effective config may not be in the file you expected.
LinkedIn hook
The bug may be in an override file, not the main unit.
Question: How often do systemd drop-ins explain a service that suddenly changed behavior?
experiments
A/B tests to run
Metric: shorts_3_second_hold_rate
A: The bug may live in the override.
B: Read effective unit fragments first.