Locate when the system halted and reconstruct why by inspecting wtmp entries and the systemd journal. 17.01.2026 | reading time: 3 min When a server stops unexpectedly or a user questions downtime, the first step is to ask when the machine actually halted and whether it was clean; this lesson shows how to extract that timeline from the wtmp record and the systemd journal so he can quickly answer both simple and forensic questions. Demonstration: extract events with last and journalctl Run `last -x` to read the binary wtmp record and `journalctl --list-boots` to list boot IDs; here is a practical example that shows both commands and representative output: ```$ last -x | grep -E "shutdown|reboot" reboot system boot 5.15.0-70-generic Fri Jan 16 09:12 still running shutdown system down 5.15.0-70-generic Fri Jan 16 08:59 - 09:12 (00:13) reboot system boot 5.15.0-70-generic Thu Jan 15 07:45 - 08:59 (01:14) shutdown system down 5.15.0-70-generic Thu Jan 15 07:44 - 07:45 (00:01) ``` And to inspect the previous boot's shutdown messages use `journalctl --list-boots` then `journalctl -b -1 -e`, which may show messages like: ```$ journalctl --list-boots -1 9b2c4d5... Fri 2026-01-15 07:44:00 — Fri 2026-01-15 08:59:00 0 af3d6e1... Sat 2026-01-16 09:12:00 — running $ journalctl -b -1 -e systemd-shutdown[1]: Syncing filesystems and block devices. systemd-shutdown[1]: Sending SIGTERM to remaining processes. systemd-shutdown[1]: Shutting down. ``` Dig deeper and common pitfalls Look at `/var/log/wtmp` (used by last) and its rotated copies when history seems missing, remember that `last` shows both "reboot" and "shutdown" records so interpretation matters, and correlate journal entries, syslog, and uptime data (for example `who -b` or `uptime -s`) to distinguish crashes from graceful shutdowns; also check log rotation and retention policies because old wtmp files may be archived or truncated. When to use which log Use `last -x` for a quick timeline from wtmp, use `journalctl -b -1` to read the previous boot's shutdown messages and service stops, check syslog or /var/log/messages for distributions without systemd, and consult audit or hardware logs when the cause is unclear; combining these sources gives a traceable chain from signal to shutdown. Next steps for the investigator Start with `last -x` to establish times, then jump into `journalctl` with the appropriate boot ID to read shutdown sequences, correlate with application logs and cron jobs, and if required set persistent journal storage or increase log retention so future investigations are easier; continue practicing on real systems to gain speed and confidence. Final note Mastering shutdown forensics is a small, high-leverage skill that makes troubleshooting faster and outages less mysterious; to deepen skills consider formal study and exam preparation such as CompTIA Linux+ or LPIC-1, with intensive courses available at bitsandbytes.academy. Join Bits & Bytes Academy First class LINUX exam preparation. boot-process utilities troubleshooting
