Failure triage

Triage an unresponsive edge service by its last useful state

A short evidence sequence can separate process failure, resource contention and an application that is alive but stuck.

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

Retrospective period: October 2026. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.

Related reading

← More guides & analysisCompare hardware →