Search Our Database

Introduction

Monitoring system reboots is a critical part of managing and maintaining server uptime and stability. On Linux-based systems, unexpected or unplanned reboots can result from hardware issues, kernel panics, system crashes, power failures, or administrative errors. Identifying the cause and time of such reboots is essential for troubleshooting and improving system reliability.

One of the simplest and most widely used commands to analyze system reboots is the last command. This tool reads from the /var/log/wtmp file, which logs user logins and system events, including reboots. When used effectively, the last command can help system administrators determine when a system reboot occurred, whether it was clean, and if it was potentially unexpected.

This article is intended for Linux system administrators, DevOps engineers, and support technicians who need to investigate system reboots. It applies to most major Linux distributions, including Ubuntu, CentOS, Debian, and Red Hat Enterprise Linux. The solution can be implemented on any Linux system that maintains standard log files and includes the last utility, which is part of the util-linux package.

The steps below will guide through checking for reboots using the last command, interpreting its output, and correlating it with potential causes. It will also highlight possible challenges, such as log rotation or truncated logs, which may limit the ability to retrieve historical data.

Prerequisites

• A Linux system with access to the terminal.
• util-linux package installed (typically pre-installed on most distributions).
• Sudo privileges to access log files if required.
• Log file /var/log/wtmp must exist and be readable.

Step-by-step Guide

Step 1: Run the last Command to View Reboot History

Use the last command with the reboot argument to display system reboot records.

last reboot

last -x

Step 2: Interpret the Output

A typical output of last reboot looks like this:

reboot   system boot  5.4.0-122-generic Mon Aug 12 13:23   still running
reboot   system boot  5.4.0-122-generic Mon Aug 12 10:12 - 13:23  (03:11)

Each line includes:

• The event type (reboot or shutdown)

• Kernel version

• Date and time of the event

• Duration the system was up (if applicable)

Unexpected reboots typically show no preceding shutdown event. This could indicate a crash or hardware issue.

Step 3: Check for Preceding Shutdown Events

Use the last -x command to check if a shutdown event occurred before a reboot. A clean shutdown should appear like this:

shutdown system down  Mon Aug 12 10:11 - 10:12  (00:01)
reboot   system boot  Mon Aug 12 10:12 - 13:23  (03:11)

If the shutdown line is missing before a reboot entry, it may indicate a forced reboot or crash.

Step 4: Identify Gaps or Missing Entries

Review the timestamps between shutdown and reboot entries. Long gaps may indicate downtime due to power loss or hardware failure.

Also, note if the uptime is unusually short (e.g., only a few seconds or minutes), which may suggest a boot loop or failed update.

Step 5: Cross-Reference with Other Logs

To further diagnose the cause of a reboot, check the following logs:

journalctl -b -1

Conclusion

By using the last command along with its extended options, it is possible to effectively trace reboot history and detect abnormal shutdowns or unexpected system restarts. This method helps pinpoint the timing of an issue and guides further analysis through additional system logs.

To extend this analysis, consider setting up automated monitoring tools that alert on unexpected reboots or utilize persistent logs across reboots for long-term audits.

Should you have any inquiries about the guidelines, please feel free to open a ticket through your portal account or contact us at support@ipserverone.com. We’ll be happy to assist you further.