How to check if a kernel ring buffer is active in Linux

LinuxLinuxBeginner
Practice Now

Introduction

In this lab, you will learn how to check if the kernel ring buffer is active in Linux. The kernel ring buffer is a vital component for understanding system events and troubleshooting. You will explore three methods to access and inspect its contents: using the dmesg command to view the buffer directly, verifying its presence and content via the /proc/kmsg file, and finally, utilizing journalctl to examine kernel logs managed by the systemd journal. These steps will provide you with practical skills to monitor and analyze kernel messages on your Linux system.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL linux(("Linux")) -.-> linux/BasicFileOperationsGroup(["Basic File Operations"]) linux(("Linux")) -.-> linux/TextProcessingGroup(["Text Processing"]) linux/BasicFileOperationsGroup -.-> linux/cat("File Concatenating") linux/BasicFileOperationsGroup -.-> linux/less("File Paging") linux/TextProcessingGroup -.-> linux/grep("Pattern Searching") subgraph Lab Skills linux/cat -.-> lab-558723{{"How to check if a kernel ring buffer is active in Linux"}} linux/less -.-> lab-558723{{"How to check if a kernel ring buffer is active in Linux"}} linux/grep -.-> lab-558723{{"How to check if a kernel ring buffer is active in Linux"}} end

Check buffer with dmesg

In this step, you will learn how to use the dmesg command to view the kernel ring buffer. The kernel ring buffer is a special area in memory where the Linux kernel stores messages about hardware, device drivers, and system events. These messages are crucial for troubleshooting and understanding what's happening at a low level on your system.

Think of the kernel ring buffer as a logbook for the kernel. When something important happens, like a device being detected or an error occurring, the kernel writes a message to this buffer. dmesg is the tool you use to read these messages.

Open your terminal if it's not already open. You can do this by clicking the Xfce Terminal icon on the left side of your desktop.

Now, type the following command and press Enter:

dmesg

You will see a lot of output scrolling through your terminal. This is the content of the kernel ring buffer. The output might look something like this (the exact content will vary depending on your system and how long it's been running):

[    0.000000] Linux version 5.15.0-xx-generic (buildd@lcy02-amd64-xx) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #xx-Ubuntu SMP Tue Feb 20 15:48:58 UTC 2024
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-xx-generic root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ro console=ttyS0,115200
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
...
[   10.123456] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[   10.567890] usb 1-1: New USB device found, idVendor=xxxx, idProduct=xxxx
[   10.567890] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
...

The timestamps at the beginning of each line indicate the time elapsed since the system booted.

Because the output can be very long, it's often useful to pipe the output of dmesg to a pager like less or more. This allows you to scroll through the output page by page.

Try this command:

dmesg | less

Now you can use the arrow keys to scroll up and down, and press q to exit less.

You can also filter the output of dmesg using grep to search for specific keywords. For example, to see messages related to USB devices, you could use:

dmesg | grep -i usb

The -i option makes the search case-insensitive.

Using dmesg is a fundamental skill for diagnosing hardware issues and understanding system boot processes in Linux.

Click Continue to proceed to the next step.

Verify buffer in /proc/kmsg

In the previous step, you used the dmesg command to view the kernel ring buffer. Now, let's explore where dmesg gets its information from. The kernel ring buffer is exposed as a virtual file in the /proc filesystem, specifically at /proc/kmsg.

The /proc filesystem is a special filesystem in Linux that provides information about processes and other system information. It's a way for the kernel to communicate with user-space programs. Files in /proc are not real files on disk; they are generated on the fly by the kernel when you access them.

The /proc/kmsg file contains the same kernel messages that dmesg displays. However, reading directly from /proc/kmsg is a bit different. dmesg processes and formats the output for easier reading, while reading /proc/kmsg directly gives you the raw messages.

Let's try reading the content of /proc/kmsg using the cat command.

Open your terminal if it's not already open.

Type the following command and press Enter:

cat /proc/kmsg

You might see some output, but it might not be as easy to read as the dmesg output. Also, reading /proc/kmsg can sometimes block if there are no new messages, or it might show messages that have already been read.

<level>message
<level>message
...

The <level> part indicates the log level of the message (e.g., critical, error, warning, info, debug).

While you can read /proc/kmsg directly, dmesg is the standard and recommended tool for viewing the kernel ring buffer because it provides better formatting and filtering options. Understanding that /proc/kmsg is the source helps you understand how dmesg works under the hood.

For most practical purposes, you will use dmesg rather than reading /proc/kmsg directly. This step is mainly to show you the underlying source of the dmesg output.

Click Continue to move on to the next step, where we'll look at a more modern logging system.

Inspect logs with journalctl

In the previous steps, you learned about the kernel ring buffer and how to view its contents using dmesg. While dmesg is great for kernel messages, modern Linux systems use a more comprehensive logging system called systemd-journald. The journalctl command is the primary tool for interacting with the systemd-journald journal.

systemd-journald collects log messages from various sources, including the kernel (like the messages you saw with dmesg), system services, applications, and even standard output and standard error of processes. It stores these logs in a structured, indexed format, making it easier to search and filter messages.

Let's explore the journalctl command.

Open your terminal if it's not already open.

Type the following command and press Enter:

journalctl

This command will display all the log messages collected by systemd-journald. Similar to dmesg, the output can be very long and is typically piped to a pager like less automatically.

-- Journal begins at Tue 2024-07-23 10:00:00 UTC, ends at Tue 2024-07-23 10:30:00 UTC. --
Jul 23 10:00:01 hostname systemd[1]: Starting Network Manager...
Jul 23 10:00:02 hostname kernel: Linux version 5.15.0-xx-generic (...)
Jul 23 10:00:03 hostname systemd[1]: Started Network Manager.
Jul 23 10:00:04 hostname systemd[1]: Starting OpenSSH server daemon...
...

You can use the arrow keys to scroll and press q to exit the pager.

journalctl has many options for filtering logs. Here are a few examples:

To see only kernel messages (similar to dmesg):

journalctl -k

To see logs from a specific service, for example, the SSH service:

journalctl -u ssh.service

To see logs since a specific time, for example, since "today":

journalctl --since "today"

To see the most recent logs and follow new messages as they arrive (like tail -f):

journalctl -f

Press Ctrl+C to exit the journalctl -f command.

journalctl is a powerful tool for system administration and troubleshooting. It provides a centralized location for logs and flexible options for viewing and filtering them.

Experiment with some of the journalctl options in your terminal to see how they affect the output.

Click Continue to complete this lab.

Summary

In this lab, you learned how to check if the kernel ring buffer is active in Linux. You started by using the dmesg command to view the contents of the kernel ring buffer, which stores important messages about hardware, device drivers, and system events. You saw how dmesg displays these messages with timestamps, providing a low-level log of system activity.

You also learned that the output of dmesg can be extensive and that piping it to a pager like less or more is a useful technique for navigating the output. This initial step demonstrated the primary method for accessing the kernel ring buffer's contents and understanding its role in system monitoring and troubleshooting.