Linux udevadm monitor 如何区分内核事件和规则动作

第一次排查 USB、磁盘或虚拟块设备时，我常看到 udevadm monitor 连续打印两组近似的内容。它们不是重复日志：--kernel 看到的是内核发出的 uevent，--udev 看到的是 udev 规则处理后的事件。判断规则是否介入，关键是同时看事件通道、ACTION、DEVPATH 和属性，而不是只盯着某一行输出。

先把监听对象拆成 kernel 与 udev 两条通道

先开一个观察窗口，分别执行下面两条命令。它们只负责选择事件来源，不会修改 udev 规则：

# 分别观察内核事件和 udev 规则处理后的事件
udevadm monitor --kernel
udevadm monitor --udev

# 同时观察两条通道，便于对照同一个设备动作
udevadm monitor --kernel --udev

示意输出里，内核事件通常先出现，随后才有 udev 事件。两者可能共享同一 DEVPATH 和 ACTION=add，但出现时间不同。这里的“先后”只说明观察到的处理阶段，不代表 udev 一定为每个字段创建了新值。

用属性和 subsystem 过滤掉无关噪声

不加参数时，设备事件一多就很难定位。排查块设备时，我更常用属性和 subsystem 过滤：

# 只看 udev 阶段，并打印便于比对的属性
udevadm monitor --udev --property --subsystem-match=block

# 需要区分设备类型时，把 devtype 写进匹配条件
udevadm monitor --kernel --property --subsystem-match=block/disk

--property（短参数 -p）会把事件属性一并打印；--subsystem-match（短参数 -s）按 subsystem[/devtype] 过滤。常用核对字段如下：

从 ACTION、DEVPATH 和时间差判断规则是否介入

真正有用的判断顺序是：先看事件通道，再对比 DEVPATH，然后观察 ACTION 和属性差异。若同一设备先出现 kernel 的 add，稍后出现 udev 的 add，这符合“内核通知—udev 处理”的基本观察模型。若只看 udev 输出，很容易把 DEVNAME、权限或标签等规则结果误写成内核事件。

规则动作也不等于任意脚本都同步完成。monitor 关注的是事件消息与规则处理后的广播，不能单凭一行输出证明某个外部程序已经执行完。要查时序，保留 -k、-u 两路；要查属性来源，打开 -p；要查规则为什么匹配，则进入下一步。

把 monitor 结果和规则测试分开验证

拿到 sysfs 路径后，可以用 udevadm test 模拟一次规则处理。它和 monitor 的职责不同：

# 对指定 sysfs 路径模拟 add，查看规则匹配和处理输出
# 这里的路径只是示例，实际值应从 DEVPATH 或 sysfs 中确认
udevadm test --action=add /sys/class/block/loop0

# 只看实时设备事件，不把模拟测试当成真实插拔
udevadm monitor --kernel --udev --property

test 适合回答“规则会怎样处理这个设备”，monitor 适合回答“真实事件何时到达、经过了哪一层”。二者结果不一致时，先检查模拟路径、ACTION 和当前规则加载状态，不要直接修改匹配条件。

相关问题

为什么只看到 Kernel device events？

可能只启用了 --kernel，也可能 udev 阶段尚未产生可见事件。先确认命令没有带互斥过滤，再用一个明确的 subsystem 缩小范围。

怎么只观察某类块设备？

使用 --subsystem-match=block；若还要区分设备类型，再写成 block/disk 等具体匹配。

规则文件改完，monitor 会重新加载它吗？

monitor 本身只是监听器，不负责重载规则。规则更新后应按发行版的 systemd-udevd 管理方式重新加载，再用 udevadm test 和真实事件分别确认。

记住这条边界就够实用：kernel 是设备事件的起点，udev 是规则处理后的观察点；用 DEVPATH 对齐对象，用 ACTION 判断动作，用 -p 和 -s 减少噪声，排查会比单看一段连续输出可靠得多。