Where Does printk Output Go? A Complete Guide to Linux Kernel Logging

Kernel‑side implementation of printk

In the Linux kernel, printk is the primary C‑like logging function. Developers usually call its wrappers such as pr_err, pr_info, or pr_debug, which add log level and module information before delegating to printk. printk writes each log entry into a dedicated ring buffer allocated by the kernel. The ring buffer is an array‑based circular queue; when it becomes full, new entries overwrite the oldest ones. Its size can be adjusted via kernel parameters.

After placing a message in the ring buffer, printk also forwards the entry to the system console subsystem so that it can appear on the console device.

User‑space ways to read kernel logs

There are three main mechanisms for user‑space programs to retrieve the kernel log:

Running the dmesg command.

Reading the /proc/kmsg file (e.g., with cat /proc/kmsg).

Calling the klogctl function from glibc.

dmesg implementation

By default, dmesg reads from /dev/kmsg. When it opens this device, the kernel creates a private file instance that contains a seq variable pointing to the next unread log entry in the ring buffer. Initially, seq points to the oldest entry.

During execution, dmesg repeatedly calls read on the file, each time retrieving one log record and incrementing seq so that the next call reads the following entry. The loop continues until the buffer is exhausted, after which dmesg exits.

Reading /proc/kmsg

The cat /proc/kmsg command works similarly to dmesg, but it reads from /proc/kmsg instead of /dev/kmsg. The key difference is that /proc/kmsg shares a single global static variable

syslog_seq</> among all readers. Consequently, when multiple processes read <code>/proc/kmsg

concurrently, they compete for the same log entries, leading to incomplete or interleaved views. This is why dmesg prefers /dev/kmsg.

Using klogctl

The klogctl function is a thin glibc wrapper around the syslog system call. It accepts commands such as SYSLOG_ACTION_READ, which reproduces the behavior of cat /proc/kmsg. Because it ultimately invokes the same kernel logic, it suffers from the same global syslog_seq limitation.

System console output

When the kernel writes to the ring buffer, it also notifies the system console. The console maintains its own console_seq pointer to track the next message to display. Console output is filtered by log level; by default, levels up to debug (level 7) are shown, while lower‑priority messages may be suppressed. The log level can be changed via the loglevel kernel parameter.

On a typical machine, the console corresponds to the text shown during boot. After the graphical environment starts, you can still view console output by switching to a virtual terminal (e.g., Ctrl+Alt+F1).

Why kernel logging matters for developers

Understanding printk and the logging pipeline helps kernel developers debug issues and allows application developers to monitor system health. For example, when the kernel kills a process due to out‑of‑memory conditions, it logs a message with pr_err. By inspecting dmesg, you can confirm whether a process termination was caused by the OOM killer.

Monitoring error‑level and higher logs enables early detection of abnormal system behavior, allowing timely manual intervention when necessary.

In summary, the printk ecosystem—from kernel ring buffer to user‑space readers—provides a vital feedback channel for both kernel and application developers, and a solid grasp of its mechanics is essential for effective system troubleshooting.