How to Quickly Identify Unexpected Linux Server Reboots and Their Causes

1. Three methods to quickly find reboot records

Understanding when a server rebooted and how many times it has happened is the first step; three simple commands cover all major Linux distributions.

1. Direct query: who -b

who -b

Example output: system boot 2025-12-21 10:32 – shows the last boot time instantly.

2. History query: last reboot

last reboot -n 10 -F

Parameters: -n 10 displays the most recent ten entries; -F prints full date‑time, kernel version and trigger method, giving a clear reboot timeline.

3. Detailed log search

Log file locations differ by distribution; use the appropriate command to grep for "reboot".

General (CentOS/RHEL): cat /var/log/messages | grep "reboot" Ubuntu/Debian: cat /var/log/syslog | grep "reboot" systemd‑based systems: journalctl -xb | grep "reboot" (the -x flag adds explanatory text, -b limits output to the current boot).

2. Four dimensions to pinpoint the reboot culprit

1. Kernel logs – hardware or kernel failures

dmesg | grep -E "error|warn|fail"

ATA error

– disk problems such as bad sectors or loose connections. Memory error – RAM faults, requiring memory testing. kernel panic – incompatible kernel version or driver issues. CPU overheating – fan or heatsink malfunction.

2. Crash logs – program‑induced reboots

# List all coredump records
coredumpctl list
# Show details for a specific PID (replace 1234 with the actual PID)
coredumpctl info 1234

The displayed stack trace points directly to the offending binary or library.

3. Service & resource issues

Critical services (nginx, mysql, sshd) may crash and trigger a reboot; also check for resource exhaustion.

# nginx error log
cat /var/log/nginx/error.log
# mysql error log
cat /var/log/mysql/error.log

Memory shortage – review historical data from monitoring tools such as nmon or Prometheus.

Disk full – df -h, especially the /var partition, can prevent log writes.

CPU saturated – top reveals runaway processes.

4. Human actions & scheduled tasks

history | grep "reboot"

Search shell history for manual reboot commands.

# User crontab
crontab -l
# System crontab
cat /etc/crontab

Identify accidental reboots or automated jobs that may have caused a restart.

3. Common pitfalls for beginners

1. No reboot record in /var/log/messages ?

On Ubuntu/Debian check /var/log/syslog instead.

Verify disk space with df -h and clean unnecessary files.

Ensure log readability: sudo chmod 644 /var/log/messages.

2. Overwhelming journalctl output

journalctl -xb -p err | grep "reboot"

Filters to error‑level entries related to reboots.

3. Quickly determine hardware failure

Inspect kernel logs for ATA, memory, or CPU warnings.

Use ipmitool to query hardware status if IPMI is supported.

Physical inspection: check server LEDs, fan operation, and temperature (see images).

Conclusion

The core workflow for Linux server reboot troubleshooting is: first retrieve the reboot time with who -b or last reboot, then examine kernel logs, coredumps, service logs, resource usage, and finally human or scheduled actions. Regular log backups and proactive monitoring dramatically reduce the time needed to resolve unexpected reboots.