Linux Survival Basics
Risk: safeInspect 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-workerBefore you run this
Risk: safe. Do not edit from memory after reading this; make a deliberate unit or drop-in change and reload systemd when applying a fix.
Expected output
The main service unit followed by drop-in override contents.
System impact
Nothing changes. systemctl prints the effective unit file fragments and drop-ins in order.
Recovery / rollback: no state is changed.
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.
Watch this command run
Example output from a temporary Linux lab
This example uses disposable sample files and sanitized output so you can inspect the shape of the result before touching a real system.
$ 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'.$ 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=criticalView reproducible demo details
This page shows the sanitized shell transcript and the setup steps needed to reproduce the example.
Lab setup steps
systemctl status app-worker --no-pager --lines=50systemctl cat app-worker
next steps
Related commands
Compare Failure Output With the Effective Unit
Put the failed step next to the unit config that created it.
systemctl status app-worker --no-pager --lines=50 && systemctl cat app-worker
Read the Failure Cause in systemctl Status
The status page often tells you the failed startup step before you open every log.
systemctl status app-worker --no-pager --lines=50
Reset Failed State After Capturing Evidence
Clear the red failed state only after you have captured the evidence.
systemctl reset-failed app-worker
Print the Exact systemd Exit Fields
Turn a noisy service failure into four fields you can paste into an incident note.
systemctl show app-worker --property=Result,ExecMainCode,ExecMainStatus,NRestarts --no-pager
Show Failed systemd Units
One command tells you which services systemd already knows are broken.
systemctl --failed --no-pager
Study mapping
Use this as independent command practice: read the notes, predict the output, then compare it with the example before using a real shell.
Useful for
- LPIC-1 style command-line practice
- LFCS style performance tasks
- Linux+ style troubleshooting review
Independent study support only. No affiliation, endorsement, exam dumps, or real exam questions.