Diagnose a Single-Server Crash with Concrete Linux Evidence
MetaSoftware Engineer · Technical ScreenLast updated
Walk through a single-server crash investigation using Linux service, kernel, memory, disk, and boot evidence while planning safe recovery.
A single server has crashed. Walk through how you would determine what failed, restore service safely, and identify the root cause. Explain the concrete commands or evidence you would use at each step and how the result changes your next action.
Constraints
For this exercise, assume a Linux server with systemd, access to a management console, and permission to inspect logs and metrics. These are diagnostic assumptions; no cause, application, redundancy arrangement, or permission to destroy evidence is implied. Distinguish a crashed application, an unreachable host, and a rebooted or halted operating system.
Clarifying Questions
- Is the host unreachable, or is one service unavailable while the host responds?
- When did the failure start, what user impact exists, and did a deployment or infrastructure change precede it?
- Is there a healthy replica, and are persistent data or in-flight writes at risk?
Hints
Hint 1
Branch on observations: An SSH failure alone does not identify a kernel crash. Separate network reachability, host health, and application health.
Follow-up questions
- What evidence would distinguish an out-of-memory kill from an application exception?
- What can you inspect if the server cannot boot far enough to accept SSH?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.