First ask what still responds
Check whether Linux is reachable, whether the service process exists and whether the application can return a bounded health response. These are separate observations. Record the last successful request and any recent update before restarting anything. A restart may restore operation, but it can also erase the state needed to understand the fault. Use the least disruptive observation that answers the next question.
If the process has exited
Preserve the exit status, service-manager state and nearby logs. systemd documents restart policy, delays and startup timeouts; inspect the configured behaviour before interpreting a stream of new processes as independent incidents. Distinguish a failed initialization from a crash after useful work. Confirm the active release and required files so a missing asset is not repeatedly investigated as an intermittent inference problem.
If the process is waiting
Look for a request stuck on an input, output or dependency. Compare the application’s last stage marker with its normal sequence. A camera that stopped delivering frames and a model that cannot complete a request may need different recovery actions. Keep health checks bounded so the diagnostic endpoint does not join the same stalled queue it is supposed to describe.
If the system is under pressure
Linux Pressure Stall Information exposes time lost to CPU, memory and I/O contention. Compare those signals with the incident timeline and the accepted workload. They can help locate a resource bottleneck without establishing its cause by themselves. Reduce or pause restartable work according to the service policy, then observe whether the control path recovers. Avoid changing several resource settings before capturing the original state.
Resume with a stated confidence level
After recovery, run a small known task and check essential peripherals. Classify the incident as explained, mitigated or still unresolved, and keep the supporting observations. Add a missing stage marker or bounded check when it would make the next incident easier to separate. The goal is a shorter path from symptom to evidence and a controlled return to service, rather than a universal restart command presented as a diagnosis.
Sources & publication notes
- systemd: service startup, restart and shutdown semantics ↗
- Linux kernel: Pressure Stall Information ↗
Retrospective period: October 2026. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.