Diagnose a Single-Server Crash with Concrete Linux Evidence

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? ```hint Branch on observations An SSH failure alone does not identify a kernel crash. Separate network reachability, host health, and application health. ``` ### What a Strong Answer Covers - Impact assessment, safe mitigation, and preservation of volatile evidence when feasible. - A stepwise host/service/resource investigation with concrete Linux commands. - Correlation with changes, validation after recovery, and prevention tied to the proven cause. ### 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?