View Previous Boot Logs with Journalctl

01/09/2025

0 Views 0

SaveSavedRemoved 0

How to View Previous Boot Logs in Linux with Journalctl

When a Linux system crashes or fails to boot properly, troubleshooting can be a challenge. The logs from the current, working session won’t contain the critical error messages that occurred during the failure. To solve the mystery, you need to access the logs from the previous, failed boot. Fortunately, modern Linux systems using systemd provide a powerful tool for this exact purpose: journalctl.

This guide will walk you through how to use journalctl to access historical boot logs, helping you diagnose everything from kernel panics to failing services.

Before You Begin: Ensure Persistent Logging is Active

The systemd journal can store logs in two ways: temporarily in memory or persistently on disk. For you to be able to view logs from a previous boot, logging must be configured to be persistent.

By default, logs are often stored in /run/log/journal/, a directory that is cleared upon every reboot. For persistence, logs must be written to /var/log/journal/.

You can quickly check if you have persistent logging enabled by seeing if this directory exists:

ls /var/log/journal/

If the directory exists and contains files, you are all set. If not, you may need to create it manually and adjust your journald.conf file, typically located at /etc/systemd/journald.conf, to set the Storage= option to auto or persistent.

Step 1: List All Available Boot Logs

Your first step is to see a list of all the boots that the system has recorded. This allows you to identify the specific boot session you want to investigate.

To see this list, use the --list-boots flag:

journalctl --list-boots

The output will be a table showing each boot, indexed for easy reference. It will look something like this:

IDX BOOT ID                          MESSAGE
 -2 f838d7264a634107b344fdc6b9a9d8e1 Mon 2023-10-23 10:15:10 EDT—Mon 2023-10-23 10:20:05 EDT
 -1 c2a0d68a9b71458e9a2b0ec7c4a1b3f9 Mon 2023-10-23 10:20:15 EDT—Mon 2023-10-23 11:05:40 EDT
  0 a1b3e9f7d6c54e3d8f8a1c9b2a7d5e4a Mon 2023-10-23 11:05:55 EDT—Mon 2023-10-23 11:30:11 EDT

Here’s what the columns mean:

IDX: A relative offset. 0 is the current boot, -1 is the previous boot, -2 is the one before that, and so on.
BOOT ID: A unique identifier for that specific boot session.
MESSAGE: The timestamp showing the start and end time of the recorded boot log.

Step 2: Accessing Logs from a Specific Boot

Once you have the list of boots, you can easily pull up the logs for any of them using the -b (for boot) flag.

To view the logs from the most recent previous boot, you would use the offset -1. This is the most common command for troubleshooting a recent crash:

journalctl -b -1

This command will display the entire journal for the boot session that occurred just before the current one. You can then scroll through this log (using the arrow keys, Page Up/Page Down) to find error messages that occurred right before the system went down.

You can use other offsets as well:

journalctl -b 0: View logs for the current boot.
journalctl -b -2: View logs from two boots ago.

Alternatively, you can use the unique BOOT ID from the list if you need to reference a specific session from long ago:

journalctl -b f838d7264a634107b344fdc6b9a9d8e1

Actionable Advice: Filtering for Faster Troubleshooting

The full boot log can be thousands of lines long. To find the root cause of a problem quickly, you need to filter the output. The best way to do this is by piping the journalctl output to grep.

For example, to search the previous boot log specifically for lines containing the word “error” (case-insensitive), you would use:

journalctl -b -1 | grep -i "error"

This is incredibly useful for narrowing down the problem. Other common search terms include:

failed: To find services or mount points that failed to start.
critical: For critical system-level messages.
A specific service name: For example, grep sshd or grep nginx to see logs related only to those services during the failed boot.

Example of finding failed services in the previous boot:

journalctl -b -1 | grep -i "failed"

Security Tip: Reviewing Logs for Suspicious Activity

Beyond troubleshooting, regularly reviewing boot logs is a good security practice. A sudden, unexplained reboot could be a sign of a security incident. By examining the logs of the previous boot, you can look for:

Failed login attempts right before the system went down.
Services starting or stopping unexpectedly.
Kernel messages indicating hardware tampering or critical security module failures.

Mastering the journalctl -b command is an essential skill for any Linux system administrator. It transforms system crashes from complete mysteries into solvable puzzles by giving you direct access to the critical information you need.

Source: https://linuxhandbook.com/journalctl-boot-logs/