Learn through the super-clean Baeldung Pro experience:
>> Membership and Baeldung Pro.
No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.
Last updated: September 19, 2024
In Linux, shutting down properly is essential to maintain system integrity and prevent data loss. When a system shutdown is interrupted or unclean, it can cause file system damage, leaving the system vulnerable. Thankfully, Linux provides several command-line utilities to check if the last shutdown was executed successfully.
In this tutorial, we’ll discuss possible approaches to verify the last shutdown status. This will involve using commands such as last, journalctl, dmesg, and who.
To begin with, the last command reads from the /var/log/wtmp file, which logs login, shutdown, and reboot events. We can use this command with the -x option to retrieve detailed information about when the system was shut down or rebooted. This can help in troubleshooting, identifying unplanned reboots or shutdowns, and monitoring system stability over time.
Let’s execute this command in the shell and pipe it to grep to focus on shutdown and reboot events:
$ last -x | grep -E 'reboot|shutdown'
reboot system boot 6.8.0-40-generic Wed Sep 11 13:33 still running
shutdown system down 6.8.0-40-generic Wed Sep 11 13:32 - 13:33 (00:00)
reboot system boot 6.8.0-40-generic Wed Sep 11 12:27 - 13:32 (01:05)
reboot system boot 6.8.0-40-generic Tue Sep 10 17:22 - 13:32 (20:10)
shutdown system down 6.8.0-40-generic Tue Sep 10 17:22 - 17:22 (00:00)
reboot system boot 6.8.0-40-generic Tue Sep 10 11:40 - 17:22 (05:41)
reboot system boot 6.8.0-40-generic Mon Sep 9 17:45 - 17:22 (23:36)
shutdown system down 6.8.0-40-generic Mon Sep 9 17:45 - 17:45 (00:00)
reboot system boot 6.8.0-40-generic Mon Sep 9 16:46 - 17:45 (00:58)
reboot system boot 6.8.0-40-generic Mon Sep 9 14:23 - 17:45 (03:21)
shutdown system down 6.8.0-40-generic Mon Sep 9 14:23 - 14:23 (00:00)
reboot system boot 6.8.0-40-generic Mon Sep 9 12:44 - 14:23 (01:39)
reboot system boot 6.8.0-40-generic Mon Sep 9 12:37 - 14:23 (01:46)
shutdown system down 6.8.0-40-generic Mon Sep 9 12:36 - 12:37 (00:00)
reboot system boot 6.8.0-40-generic Mon Sep 9 12:14 - 12:36 (00:22)
In this output, we can see that the output lists several shutdowns over a short period. For example, the most recent shutdown occurred on Wed Sep 11 at 13:32, followed by a quick reboot at 13:33.
Most Linux distributions use systemd as the default init system. Therefore, we can use journalctl to access system logs, including shutdown and reboot information. Specifically, the journalctl command with the -b option shows the current or specified boot logs. This information is useful for diagnosing issues or verifying if the shutdown was performed correctly.
For instance, to check the logs from the last boot, we can use the -b -1 option with the journalctl command and pipe it to grep to filter the output for shutdown logs:
$ journalctl -b -1 | grep -i shutdown
Sep 11 12:27:22 root systemd[1]: Starting Record System Boot/Shutdown in UTMP...
Sep 11 12:27:22 root systemd[1]: Finished Record System Boot/Shutdown in UTMP.
Sep 11 12:27:26 root systemd[1]: Started Unattended Upgrades Shutdown.
Sep 11 12:42:58 root systemd[1203]: Reached target Shutdown.
Sep 11 13:32:51 root systemd[1]: Condition check resulted in Ubuntu core (all-snaps) system shutdown helper setup service being skipped.
Sep 11 13:32:52 root systemd[1937]: Reached target Shutdown running GNOME Session.
Sep 11 13:32:52 root systemd[1937]: Starting Restart DBus after GNOME Session shutdown...
Sep 11 13:32:52 root systemd[1937]: Stopped target Shutdown running GNOME Session.
Sep 11 13:32:52 root systemd[1937]: Started Restart DBus after GNOME Session shutdown.
Sep 11 13:32:53 root systemd[1937]: Reached target Shutdown.
Sep 11 13:32:56 root systemd[1]: Stopping Record System Boot/Shutdown in UTMP...
Sep 11 13:32:56 root systemd[1]: Stopped Record System Boot/Shutdown in UTMP.
Sep 11 13:32:57 root systemd[1]: Reached target System Shutdown.
Sep 11 13:32:57 root systemd[1]: Reached target Late Shutdown Services.
Sep 11 13:32:57 root systemd-shutdown[1]: Syncing filesystems and block devices.
Sep 11 13:32:57 root systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Here, we can see the system’s shutdown process logs, indicating that it reached the shutdown target and synced filesystems, which suggests a clean shutdown.
The dmesg command shows the kernel-related logs from the kernel ring buffer, including information about the filesystem during the boot process. We can filter these kernel logs for a particular filesystem like EXT4 to check for proper mounting or errors. This helps us identify potential issues with the filesystem integrity, ensuring that the system is stable and error-free after a reboot.
Let’s execute the dmesg command with sudo and pipe it to the grep to filter the log messages specific to the EXT4 filesystems:
$ sudo dmesg | grep -i "EXT4-fs"
[ 2.525134] EXT4-fs (sda3): mounted filesystem 9a0158fe-c04b-4de8-a6f5-020b3d8ccefa ro with ordered data mode. Quota mode: none.
[ 4.056136] EXT4-fs (sda3): re-mounted 9a0158fe-c04b-4de8-a6f5-020b3d8ccefa r/w. Quota mode: none.
This output shows that the filesystem mounted correctly during the boot process, which typically follows a clean shutdown.
The standalone who command prints the information about currently logged-in users. Specifically, when used with the -b option, it shows the information about the last system boot time, which is useful when co-relating it with shutdown events.
Let’s try running the who -b command in the shell:
$ who -b
system boot 2024-09-11 13:33
Above, we can see that the system last booted on 2024-09-11 at 13:33.
In this article, we explored the last, journalctl, dmesg, and who commands to verify the last shutdown status. The last command tracks shutdown and reboots from the log files, while the journalctl accesses system logs, offering detailed shutdown information. On the other hand, the dmesg command shows kernel logs, helping identify filesystem issues, and who checks the last system boot time.
These commands enable us to confirm clean shutdowns and troubleshoot potential system or data integrity issues, ensuring a reliable and stable Linux environment.