1. 项目概述：为什么需要调整内核的“音量旋钮”

在Linux内核开发或者驱动调试的日常里， printk 绝对是每个工程师最熟悉的老朋友。它就像内核世界里的“日志打印机”，把内核运行时的状态、错误、调试信息一股脑地输出到控制台或者系统日志里。但不知道你有没有遇到过这样的场景：系统启动时，控制台被海量的内核信息刷屏，淹没了你真正关心的那几条错误；或者，你精心编写的驱动模块，其调试信息死活不出现，让你排查问题时两眼一抹黑。

这背后，其实就是 printk 的打印等级在“作祟”。内核为每一条 printk 信息都预设了一个“音量”，只有“音量”足够大（即等级足够高）的信息，才能突破当前控制台“日志级别”的静音阈值，被我们看到。所以，“修改 printk 等级”这个操作，本质上就是在动态调整内核日志系统的“过滤器”和“扬声器”的音量。它不是一个炫技的花活，而是定位疑难杂症、优化启动体验、进行深度系统调优的必备基本功。

掌握它，意味着你能从纷繁的内核输出中，精准地捕捉到故障的蛛丝马迹，也能让系统在安静与详尽之间找到最适合当前调试状态的平衡点。接下来，我们就深入内核，把这个“音量旋钮”的调节方法彻底搞清楚。

2. 核心概念解析：理解printk的等级体系

在动手修改之前，我们必须先理解 printk 等级这套规则是如何运转的。它不是一个孤立的参数，而是一个由发送方、过滤器和最终输出共同构成的体系。

2.1 printk的八个标准等级

内核定义了八个标准的日志级别，用宏表示，数值越小，优先级越高，“音量”越大。

级别宏定义 数值 含义 典型用途
KERN_EMERG 0 紧急 系统即将崩溃或不可用。
KERN_ALERT 1 警报 需要立即采取行动。
KERN_CRIT 2 严重 严重错误情况。
KERN_ERR 3 错误 错误情况，但系统通常还能运行。
KERN_WARNING 4 警告 可能出现问题的情况。
KERN_NOTICE 5 通知 正常的、但值得注意的情况。
KERN_INFO 6 信息 信息性消息（默认级别）。
KERN_DEBUG 7 调试 调试级信息，最详细。

在代码中，我们这样使用它们： 

printk(KERN_ERR “This is an error message: %d\n”, error_code);
// 注意：KERN_ERR和后面的字符串之间没有逗号，它是一个字符串字面量前缀。

注意 ： KERN_DEBUG 是等级最低（数值最大）的，所以默认情况下最容易“静音”。很多驱动开发者在代码里写了大量 KERN_DEBUG 信息，却发现 dmesg 里看不到，问题往往就出在这里。

2.2 两个关键阈值：控制台日志级别与默认消息级别

光有发送等级还不够，内核用两个关键的阈值来决定一条消息最终能否呈现，以及呈现在哪里。

  1. 控制台日志级别 ( console_loglevel ) 这是最重要的“守门员”。只有 printk 消息的等级数值 小于 这个阈值时，消息才会被打印到 当前控制台 （如 ttyS0 , tty1 等）。它的默认值通常是 7 （在 kernel/printk/printk.c 中定义，如 DEFAULT_CONSOLE_LOGLEVEL ），这意味着所有等级为 0 到 6 的消息都会上控制台，而 7 ( KERN_DEBUG ) 则不会。

    • 为什么启动时刷屏？ 因为在系统启动早期，这个值可能被临时设置为 8 甚至 15 ，意味着所有信息（包括 DEBUG ）都上控制台，所以你会看到极其详细的启动日志。

  2. 默认消息级别 ( default_message_loglevel ) 当你在 printk 中 没有明确指定等级 时，内核就会使用这个默认等级。例如，你写 printk(“Hello World\n”) ，这条消息的等级就是 default_message_loglevel 。它的默认值通常是 4 ( KERN_WARNING )。

  3. 最低允许打印级别 ( minimum_console_loglevel ) 与 默认控制台级别 ( default_console_loglevel ) 这两个是辅助性的“硬性限制”。

    • minimum_console_loglevel ：控制台级别允许被设置的最低值（即最高优先级）。防止用户误操作将控制台级别设得太低，导致连紧急信息都不打印。
    • default_console_loglevel ：系统在启动过程中或某些重置操作后会回退到的默认控制台级别。

信息流向总结 ：一条 printk 消息产生后，内核首先检查它的等级是否高于（数值小于） console_loglevel ，是则打印到控制台。 无论是否打印到控制台，绝大多数消息都会被存入内核环形缓冲区（ring buffer） ，这就是 dmesg 命令能读取到的内容。 dmesg 命令本身也有一个 -n 参数来过滤显示级别，但它不影响内核的打印行为，只影响查看。

3. 动态修改printk等级：运行时调试的利器

当系统正在运行时，我们经常需要临时调整日志级别来捕获特定信息。这主要通过 /proc/sys/kernel/ 下的虚拟文件系统 ( procfs ) 接口实现，无需重启，即时生效。

3.1 通过/proc接口调整

这是最常用、最直接的方法。系统中会存在以下几个关键文件：

  • /proc/sys/kernel/printk ：这是最重要的文件。它一次性地展示了四个关键参数。 

    $ cat /proc/sys/kernel/printk
7    4    1    7

    这四个数字分别代表（从左到右）：

    1. console_loglevel ：当前控制台日志级别。
    2. default_message_loglevel ：默认消息级别。
    3. minimum_console_loglevel ：最低允许控制台级别。
    4. default_console_loglevel ：默认控制台级别。

  • 如何修改？ 直接向这个文件写入新的值即可。写入的格式也是四个用空格或制表符分隔的数字。 

    # 示例：将控制台日志级别设置为4（只显示WARNING及以上），默认消息级别保持4，其他不变。
# 注意：需要root权限
sudo bash -c ‘echo “4 4 1 7” > /proc/sys/kernel/printk‘

    更常见的做法是只修改第一个参数（控制台级别）： 

    # 只修改第一个参数为1（只显示ALERT和EMERG），其他参数保持原样。
# 这种方法需要先读取当前值
CURRENT=$(cat /proc/sys/kernel/printk)
sudo bash -c ‘echo “1 ${CURRENT:2:1} ${CURRENT:4:1} ${CURRENT:6:1}” > /proc/sys/kernel/printk‘
# 更稳妥的写法是使用awk
sudo bash -c ‘echo “1 $(cat /proc/sys/kernel/printk | awk \’{print $2, $3, $4}\’)“ > /proc/sys/kernel/printk‘

  • 专用控制文件 ： 在一些新版本内核中，为了更清晰，也提供了单独的文件来控制 console_loglevel ：

    • /proc/sys/kernel/printk_delay
    • /proc/sys/kernel/printk_time
    • 以及最重要的： /proc/sys/kernel/printk_console_loglevel （如果存在） 如果存在 printk_console_loglevel ，修改它将只影响控制台级别，更为方便： 
    sudo bash -c ‘echo 8 > /proc/sys/kernel/printk_console_loglevel‘ # 打开DEBUG级别到控制台
sudo bash -c ‘echo 3 > /proc/sys/kernel/printk_console_loglevel‘ # 只显示ERR及以上

3.2 使用内核启动参数（bootargs）预设

如果你在系统启动前就知道需要什么样的日志级别，或者要调试启动早期的问题，内核命令行参数是最佳选择。

通过 printk 内核参数，可以一次性设置多个级别。格式为： printk=级别参数

  • printk.device=value ： 这是最常用的参数 ，用于直接设置 控制台日志级别 。例如： 

    printk.device=8

    在GRUB配置中，你需要在 GRUB_CMDLINE_LINUX_DEFAULT 或 GRUB_CMDLINE_LINUX 变量中添加它，然后更新grub并重启。

  • printk.default=value ：设置默认消息级别。

  • printk.minimum=value ：设置最低允许控制台级别。

  • printk.console=value ：设置默认控制台级别。

实操心得 ：调试内核启动问题（比如驱动初始化失败）时，我习惯在GRUB启动菜单的Linux命令行后临时加上 printk.device=8 和 ignore_loglevel （这个参数会强制忽略所有级别检查，所有信息都打印，慎用），这样就能看到最详尽的启动日志，定位问题后再移除。

3.3 在代码中直接修改

在内核模块或内核代码中，你也可以直接修改 console_loglevel 这个全局变量。但 必须格外小心 ，因为这会全局影响所有 printk 的输出。 

#include <linux/kernel.h> // 定义了 console_loglevel

// 临时提高控制台日志级别以捕获调试信息
int old_loglevel;
old_loglevel = console_loglevel;
console_loglevel = 8; // 允许DEBUG信息打印

// ... 执行你想要调试的代码段 ...

// 恢复原来的级别
console_loglevel = old_loglevel;

注意事项 ：这种方法不是线程安全的，在多CPU环境下可能会引发问题。而且，修改后会影响整个系统的日志输出行为。通常只建议在个人调试的、非生产环境的内核模块中短暂使用，并且一定要记得恢复。更推荐的做法是通过 procfs 接口在用户空间动态控制。

4. 高级技巧与场景化应用

掌握了基本方法后，我们来看看如何组合运用这些技巧，解决实际开发中的具体问题。

4.1 精准调试：只关注你的模块

当系统中有多个模块在打印日志时，全局提高 console_loglevel 会导致信息过载。理想情况是只让你关心的模块的 DEBUG 信息可见。

方法一：按等级过滤的 dmesg 这是最简单无副作用的做法。让控制台保持安静（比如级别为4），然后使用 dmesg 命令的 -l 或 --level 参数按需查看。 

# 查看所有级别的内核消息（从缓冲区读取）
dmesg
# 只查看错误和更高级别的消息
dmesg -l err,crit,alert,emerg
# 或者使用数值，例如查看级别<=7（即所有DEBUG及以上的消息）
dmesg -n 8
# 注意：dmesg -n 8 这个命令也会临时改变 dmesg 的读取过滤器，但不会影响内核的 console_loglevel。

方法二：动态开关控制台DEBUG输出 写一个简单的Shell脚本，在需要调试时打开DEBUG输出，完成后关闭。 

#!/bin/bash
# debug_kernel.sh
DEBUG_LEVEL=8 # KERN_DEBUG
NORMAL_LEVEL=4 # KERN_WARNING

if [ “$1” = “on” ]; then
    echo “Enabling kernel DEBUG messages on console…”
    sudo bash -c ‘echo $DEBUG_LEVEL > /proc/sys/kernel/printk_console_loglevel‘
elif [ “$1” = “off” ]; then
    echo “Restoring normal kernel log level…”
    sudo bash -c ‘echo $NORMAL_LEVEL > /proc/sys/kernel/printk_console_loglevel‘
else
    echo “Usage: $0 {on|off}”
fi

4.2 优化启动速度与界面整洁度

系统启动时，特别是使用图形化显示管理器（如GDM、LightDM）时，控制台刷屏的内核信息会影响美观，甚至略微拖慢启动速度（因为串口或帧缓冲区的打印是同步操作，比较耗时）。

解决方案 ：将控制台日志级别在启动早期就设置为一个较高的值（较小的数值），例如 3 ( KERN_ERR ) 或 4 ( KERN_WARNING )。

  1. 使用内核参数 ：在GRUB配置中添加 printk.device=3 。这是最彻底的方法，从内核一开始就静音。
  2. 在initramfs或早期启动脚本中设置 ：如果无法修改内核参数，可以在系统的早期启动脚本（如 /etc/rc.local 或 systemd 的早期服务）中写入 /proc/sys/kernel/printk 。但要注意，此时可能已经有大量信息打印过了。
  3. 针对串口控制台 ：如果你通过串口调试，信息过多可能导致丢失。除了设置级别，还可以考虑增加串口波特率，或者使用 netconsole （网络控制台）来传输日志，带宽更大，更可靠。

4.3 内核模块开发中的printk等级策略

编写内核模块时，合理地使用 printk 等级是一门艺术。

  • 错误路径（Error Path） ：使用 KERN_ERR 或 KERN_CRIT 。例如，内存分配失败、硬件访问错误。

  • 正常操作提示（Normal Operation） ：使用 KERN_INFO 。例如，模块加载/卸载成功、设备探测到。

  • 详细调试信息（Detailed Debugging） ：使用 KERN_DEBUG 。这是最常用的调试级别。 务必配合条件编译 ，避免在发布版本中留下性能开销和日志噪音。 

    #ifdef DEBUG
#define my_debug(fmt, ...) printk(KERN_DEBUG “MY_MODULE: “ fmt, ##__VA_ARGS__)
#else
#define my_debug(fmt, ...) no_printk(KERN_DEBUG, fmt, ##__VA_ARGS__)
#endif

// 在代码中使用
my_debug(“Function %s entered with arg %d\n”, __func__, arg);

    编译时通过 make EXTRA_CFLAGS=”-DDEBUG” 来启用调试信息。

  • 使用动态调试（Dynamic Debug） ：对于更复杂的模块， pr_debug() 配合内核的 Dynamic Debug 功能是更强大的选择。它允许你在运行时通过 /sys/kernel/debug/dynamic_debug/control 文件，动态启用或禁用特定文件、函数甚至行号的 pr_debug() 输出，而无需重新编译模块。这需要内核配置 CONFIG_DYNAMIC_DEBUG 。

5. 常见问题排查与实操陷阱

在实际操作中，你可能会遇到一些意想不到的情况。这里记录了几个我踩过的坑和对应的解决方案。

5.1 问题：修改了/proc/sys/kernel/printk，但控制台依然安静/嘈杂

  • 可能原因1：控制台驱动问题 。 printk 消息最终需要控制台驱动（如 ttyS , fbcon , vt ）来渲染。如果控制台驱动没有正确初始化或挂起，消息可能无法显示，但 dmesg 可以查到。检查系统是否处于单用户模式、是否切换了虚拟终端（VT）。
  • 可能原因2：系统服务覆盖 。某些系统管理服务（如 syslogd , rsyslog , systemd-journald ）或桌面环境可能会在启动后重新设置日志级别。检查是否有这样的脚本或服务。
  • 排查步骤 ：
    1. cat /proc/sys/kernel/printk 确认当前值已改变。
    2. 执行 echo “Test KERN_EMERG” > /dev/kmsg 。这条命令会直接向内核日志缓冲区写入一条 KERN_EMERG 级别的消息，它应该 无论如何 都会打印到所有活动的控制台。如果没出现，基本是控制台本身的问题。
    3. 检查当前活动的控制台： cat /sys/class/tty/console/active 。

5.2 问题：dmesg命令显示“权限被拒绝”

  • 原因 ：从某个内核版本开始， dmesg 的读取权限默认只授予 root 用户，这是为了安全考虑（内核日志可能包含敏感信息）。
  • 解决方案 ：
    1. 使用 sudo dmesg 。
    2. 或者，修改 kernel.dmesg_restrict 这个 sysctl 参数（不推荐在生产环境使用）： 
      # 查看当前值，1表示受限，0表示不受限
sysctl kernel.dmesg_restrict
# 临时解除限制
sudo sysctl -w kernel.dmesg_restrict=0

5.3 问题：内核环形缓冲区被冲掉，找不到早期的启动日志

  • 原因 ：内核环形缓冲区大小固定（通常为64KB~1MB，取决于配置 CONFIG_LOG_BUF_SHIFT ）。当系统运行时间长、日志量大时，旧日志会被新日志覆盖。
  • 解决方案 ：
    1. 及时抓取 ：在系统启动后，尽快使用 dmesg > /tmp/boot.log 保存日志。
    2. 增大缓冲区 ：重新配置并编译内核，增加 CONFIG_LOG_BUF_SHIFT 的值（例如设为17，对应128KB；18对应256KB）。这需要重启。
    3. 使用持久化日志服务 ：依赖 systemd-journald 或 rsyslog 等服务，它们会主动从缓冲区读取日志并存入磁盘文件。确保这些服务在启动早期就被启用。

5.4 陷阱：忽略默认消息级别的副作用

很多开发者习惯写 printk(“something\n”) ，而不指定等级。这在默认级别为4（WARNING）时，这条消息会直接打印到控制台。如果你将 default_message_loglevel 改成了7（DEBUG），那么所有这些“裸奔”的 printk 都会从控制台消失，可能会让你误以为代码没执行。 最佳实践是：始终显式指定 printk 的日志等级 。

6. 内核日志的持久化与高级管理

对于生产系统或需要长期审计的场景，仅仅在内存中查看 dmesg 是不够的。我们需要将内核日志持久化保存。

6.1 传统方案：klogd + syslogd

这是经典的组合。 klogd 是一个守护进程，专门负责从内核环形缓冲区读取消息，并将其转发给 syslogd （或 rsyslog , syslog-ng ）。 syslogd 则根据 /etc/syslog.conf 的配置，将不同设施（facility）和级别（level）的消息写入不同的文件（如 /var/log/messages , /var/log/kern.log ）。

现在大多数主流发行版已经不再使用独立的 klogd ，其功能被集成到 systemd-journald 或 rsyslog 的 imklog 模块中。

6.2 现代方案：systemd-journald

使用 systemd 的系统，其日志由 systemd-journald 服务统一管理。它二进制格式的日志文件通常位于 /var/log/journal/ 。

  • 查看所有内核日志 ： 
    journalctl -k
# 或
journalctl --dmesg
  • 查看指定优先级以上的内核日志 ： 
    journalctl -k -p err # 查看ERROR及以上
journalctl -k -p debug # 查看所有（包括DEBUG）
  • 实时跟踪 ： 
    journalctl -k -f
  • 将内核日志持久化到系统日志文件 ： journald 默认可以配置将日志转发给 rsyslog 。确保 rsyslog 服务运行，并检查 /etc/rsyslog.conf 中是否有 kern.* 的转发规则，通常会指向 /var/log/kern.log 。

6.3 使用netconsole进行远程日志记录

在调试无显示设备（如服务器、嵌入式设备）或内核崩溃（ panic ）时， netconsole 是一个救命稻草。它将内核日志通过UDP网络包发送到另一台指定的机器上。

配置步骤简述 ：

  1. 在接收端机器（IP: 192.168.1.100）上启动 netcat 监听 UDP 514 端口（或任意端口）： 
    nc -u -l -p 514
  2. 在目标机器（要调试的设备）上，加载 netconsole 模块并指定参数： 
    # 方式1：模块参数
sudo modprobe netconsole netconsole=6666@192.168.1.50/eth0,6666@192.168.1.100/514
# 解释：本地端口6666，本地IP 192.168.1.50，网卡eth0； 目标端口514，目标IP 192.168.1.100

# 方式2：通过内核命令行参数（适用于早期启动）
# 在GRUB中添加： netconsole=6666@192.168.1.50/eth0,6666@192.168.1.100/514
    配置成功后，目标机器的内核日志就会实时发送到接收机的 nc 窗口。这对于捕获系统崩溃前的最后几条日志至关重要。

7. 性能考量与最佳实践总结

频繁的、低级别的 printk 会对性能产生可测量的影响，尤其是在高速路径（如网络数据包处理、存储IO路径）中。

  • 性能影响 ： printk 是同步的，并且会临时禁用本地CPU的中断（ local_irq_save ）。在 DEBUG 级别泛滥的驱动中，我实测过会导致网络吞吐量下降超过10%。因此， 在性能关键的代码路径中，应绝对避免使用 printk ，尤其是低级别（如 DEBUG ）的打印 。
  • 替代方案 ：
    • Tracepoints 和 Ftrace ：这是内核内置的、低开销的静态跟踪点，非常适合性能分析和事件追踪。
    • perf events ：通过 perf 工具进行性能计数和采样。
    • Dynamic Debug ：如前所述，可以做到运行时零开销（当禁用时）。
    • 内核探针（Kprobes） ：用于动态跟踪任意内核函数。
  • 最佳实践清单 ：
    1. 显式指定等级 ：永远不要使用无等级的 printk 。
    2. DEBUG信息条件编译 ：使用 #ifdef DEBUG 或 pr_debug() / Dynamic Debug 来管理调试信息。
    3. 错误信息要丰富 ： KERN_ERR 信息应包含足够上下文，如函数名、错误码、相关硬件寄存器值等。
    4. 生产环境保持安静 ：生产系统的控制台日志级别建议设为 4 ( KERN_WARNING ) 或更高，避免日志洪水。通过 syslog / journald 来收集和归档更详细的信息。
    5. 善用 /proc/sys/kernel/printk ：这是你运行时调试的瑞士军刀。写个脚本把它包装起来，方便快速切换。
    6. 理解你的日志管道 ：清楚你的系统是用的 journald 还是 rsyslog ，知道日志文件在哪里（ /var/log/messages , /var/log/syslog , /var/log/kern.log , journalctl ）。
    7. 为崩溃做准备 ：对于关键服务器，考虑配置 netconsole 或 kdump ，以便在系统崩溃时能捕获最后的信息。

修改 printk 等级，从表面看只是一个数字的变化，但它背后连通的是你对内核日志系统整体架构的理解。从控制台的实时输出，到环形缓冲区的暂存，再到持久化日志服务的归档，每一个环节都有可调节的旋钮。真正掌握它，你就能在系统沉默时让它开口说话，在它喋喋不休时让它保持安静，从而在复杂的内核世界里，始终掌控调试的主动权。

Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

特藏库房精细化管控：国产化平台联动恒湿、除酸、消杀设备实战

avatar openEuler 社区
cover

创智慧档案馆建设方案：一站式八防十防十二防温湿度管库一体化平台整体设计

avatar openEuler 社区

SysTick 系统滴答定时器

Cortex-M4的 24 位递减计数器，不是片上外设定时器（TIM）。所有 Cortex-M4 芯片都有，可移植。：产生固定周期中断，当系统时基。裸机给用，FreeRTOS 给操作系统当心跳。

avatar openEuler 社区