Hosting Operations
Risk: safeCheck Failed Dependencies for a Service
A service fails after startup, but the real blocker may be a dependent unit such as Redis, networking, a mount, or a socket.
Command
systemctl list-dependencies app-worker --failed --no-pager
Before you run this
Risk: safe. Do not assume every dependency failure is causal; inspect the dependency logs and timeline.
Expected output
A dependency tree containing failed units under the target service.
System impact
Nothing changes. systemctl prints failed dependencies for the requested unit.
Recovery / rollback: no state is changed.
When to use it
Use when a service failure mentions connection refused, missing mounts, network targets, sockets, or required local services.
When not to use it
Do not assume every dependency failure is causal; inspect the dependency logs and timeline.
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 list-dependencies app-worker --failed --no-pager
app-worker.service
● ├─redis.service
● └─network-online.target
$ journalctl -u redis -b --no-pager -n 30
Jun 25 14:19:40 vps systemd[1]: Starting redis.service - Redis data store...
Jun 25 14:19:41 vps redis-server[1998]: Fatal error, can't open config file '/etc/redis/redis.conf': Permission denied
Jun 25 14:19:41 vps systemd[1]: redis.service: Main process exited, code=exited, status=1/FAILURE
Jun 25 14:19:41 vps systemd[1]: redis.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 list-dependencies app-worker --failed --no-pagerjournalctl -u redis -b --no-pager -n 30
next steps
Related commands
Print Runtime Paths and User From systemd
Confirm the user, working directory, env file, and ExecStart systemd is actually using.
systemctl show app-worker --property=FragmentPath,DropInPaths,EnvironmentFiles,ExecStart,User,WorkingDirectory --no-pager
Find the First Failure Line for One Unit
The first failure line is often more useful than the last restart message.
journalctl -u app-worker -b --no-pager -o short-iso | grep -m1 -E 'ERROR|Failed|status='
Read Warning and Error Logs for One Failed Unit
Filter a failed unit's journal to the lines most likely to explain the stop.
journalctl -u app-worker -b -p warning..alert --no-pager -n 80
Build a Restart Loop Timeline
Restart loops make more sense when you line up starts, failures, and counters.
journalctl -u app-worker -b --no-pager -o short-iso | grep -E 'Started|Failed|Scheduled restart|Main process exited'
Spot Stale systemd Timers
The suspicious timer is the one with no next run.
systemctl list-timers --all --no-pager --plain | awk 'NR==1 || $1=="n/a" || /backup\.timer|logrotate\.timer/'
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.