Understanding Log Levels in the Linux Kernel

The Linux kernel, the core of the operating system, relies on logging to communicate critical events, errors, and debugging information. These logs are essential for diagnosing hardware issues, debugging software, and monitoring system health. To manage the volume and severity of logged messages, the kernel employs log levels, which categorize messages based on their urgency. This article explores the log levels in the Linux kernel, their usage, and how they can be configured.

What Are Log Levels?

Log levels in the Linux kernel are numerical values (0–7) that indicate the severity or priority of a log message. Lower numerical values correspond to higher urgency. These levels determine whether a message is displayed on the console, stored in the kernel ring buffer, or relayed to user-space logging systems like syslog or journald. By default, only messages with a severity higher than a configured threshold are shown on the console, while others are retained in buffers for later inspection.

The kernel's logging function, printk(), uses these levels to annotate messages. Developers and system administrators leverage them to filter noise and focus on critical events.

The Eight Log Levels

The Linux kernel defines eight log levels, each serving a specific purpose:

Using Log Levels in Kernel Code

In kernel code, developers use printk() to log messages, prefixing the message with a log level macro. For example:

printk(KERN_ERR "Network device %s: Link down\n", dev->name);        

The KERN_ERR macro injects the log level into the message string. Older kernels required manual priority prefixes (e.g., printk("<3>Error message")), but modern code uses the macros for clarity.

Continuation Messages

The KERN_CONT macro allows splitting a message across multiple printk calls without interleaving other logs:

printk(KERN_ERR "Error: ");
printk(KERN_CONT "Device %s failed.\n", dev->name);
        

Configuring Log Levels

Runtime Configuration

The kernel's log level threshold is controlled via /proc/sys/kernel/printk, which contains four space-separated values:

1. Current log level: Messages more severe than this value appear on the console.
2. Default log level: Used when no level is specified in printk().
3. Minimum allowed log level: The highest (least severe) configurable level.
4. Boot-time default log level: Set during kernel boot.

To set the console log level to 4 (KERN_WARNING), suppressing less urgent messages:

most of the time it is not permitted.

echo 4 > /proc/sys/kernel/printk         

Alternatively, use dmesg:

dmesg --console-level 4        

Boot-Time Configuration

Add the loglevel=<value> kernel parameter in the bootloader configuration (e.g., GRUB) to set the initial threshold. For example, loglevel=0 logs only emergencies.

Viewing Kernel Logs

Kernel logs are stored in a ring buffer and retrieved using:

• dmesg: A command-line utility to view and filter logs. Example: dmesg --level=err,crit shows only errors and critical messages.
• /var/log/kern.log: On many distributions, logs are persisted here via syslog.

Messages appear with their log level as a prefix (e.g., <4> for warnings). Higher-severity messages (e.g., KERN_EMERG) are often highlighted in red on the console.

Best Practices

1. Use appropriate levels: Reserve KERN_EMERG for catastrophic failures. Avoid flooding logs with KERN_DEBUG in production.
2. Avoid overlogging: Excessive logging can fill the ring buffer, causing older messages to be lost.
3. Dynamic adjustment: Temporarily raise the log level during debugging (echo 8 > /proc/sys/kernel/printk enables all levels).

Conclusion

Log levels in the Linux kernel provide a structured way to prioritize and manage system messages. By understanding their purpose and configuration, developers can write more maintainable code, while administrators gain finer control over system monitoring. Whether diagnosing a crash or debugging a driver, these levels are indispensable for maintaining a healthy Linux system.