Linux Survival Basics
Risk: safeRead the Failure Cause in systemctl Status
A systemd service is failed and you need the active state, exit status, unit paths, and the most recent failure lines in one read-only check.
Command
systemctl status app-worker --no-pager --lines=50Before you run this
Risk: safe. Do not stop at status when the failure is intermittent, old, or missing context; follow up with journalctl and systemctl show.
Expected output
A failed active state, Result value, ExecStart exit status, and recent lines showing the failing startup step.
System impact
Nothing changes. systemctl prints service metadata, process exit status, and recent journal lines.
Recovery / rollback: no state is changed.
When to use it
Use first when a specific service is failed and you need a fast summary before deeper journal or unit-file inspection.
When not to use it
Do not stop at status when the failure is intermittent, old, or missing context; follow up with journalctl and systemctl show.
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 --failed --no-pager
UNIT LOAD ACTIVE SUB DESCRIPTION
app-worker.service loaded failed failed Background job worker
api.service loaded failed failed Example API service
2 loaded units listed.$ 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'.View reproducible demo details
This page shows the sanitized shell transcript and the setup steps needed to reproduce the example.
Lab setup steps
systemctl --failed --no-pagersystemctl status app-worker --no-pager --lines=50
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
Inspect One Service Without Pager Traps
Make systemctl status safe for scripts, screenshots, and quick incident notes.
systemctl status nginx --no-pager --lines=30
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
Reset Failed State After Capturing Evidence
Clear the red failed state only after you have captured the evidence.
systemctl reset-failed app-worker
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.