udevadm settle 超时退出时怎么判断设备事件是否还没处理完

在磁盘、网卡或容器启动脚本里，udevadm settle 经常被当成“设备已经准备好”的总开关。真正需要判断的是：它等待的是整个 udev 事件队列，还是某一次触发；命令返回非零时，是队列在超时前没有清空，还是命令本身没有正常完成。

如果 udevadm settle --timeout=N 返回 0，表示它观察到事件队列在 N 秒内变空；如果 N 大于 0 时返回非 0，首先应按“队列没有在时限内清空”处理。--timeout=0 只做即时检查，不能当成等待动作。

先分清“全局队列”与“本次事件”

高压启动流程最容易出现的误判，是把“等待结束”直接等同于“指定设备可以使用”。udevadm settle 的职责是观察 udev 事件队列，直到当前事件全部处理完；它不是按设备名称筛选的等待器，也不会替应用验证挂载、驱动功能或网络服务是否已经完成。

如果前一步是 udevadm trigger，并且目标是只等待这次命令触发的事件，可以考虑 trigger --settle。手册明确区分了两者：trigger --settle 只等待同一条命令触发的事件，而单独调用 udevadm settle 会等待所有当前事件。这个取舍很关键：全局等待的覆盖面更大，但在共享主机或启动高峰中更容易被无关事件拖长。

默认 120 秒并不代表一定会等满

settle 的默认最大等待时间是 120 秒。队列提前变空时命令就会返回，不会为了凑满 120 秒继续睡眠；真正到达上限仍未清空时，命令才按非零状态退出。因此，“运行时间接近 120 秒”与“立即返回非零”都应该被纳入故障现场。

对启动脚本而言，建议把等待上限显式写出来，让这个外部依赖的成本可见。例如下面的示例把等待限制在 15 秒，并把退出码保存下来。命令块中的注释只解释判断目的，不假装给出某台机器的实际输出。

#!/usr/bin/env bash
set -u

# 给设备事件队列一个有限等待预算，避免无限拖住启动链路。
udevadm settle --timeout=15
settle_status=$?

# 0 表示在 15 秒内观察到队列清空，非 0 先按超时或未清空处理。
if [ "$settle_status" -eq 0 ]; then
    echo "udev event queue is empty"
else
    echo "udev event queue did not become empty in time" >&2
    # 这里接入重试、降级或告警；不要继续假设所有设备都已就绪。
    exit "$settle_status"
fi

用退出码判断“还没处理完”

判断核心不在输出文本，而在退出码和你传入的超时值。对 --timeout=N 且 N 大于 0 的情况，返回 0 可以解释为“队列在时限内变空”；返回非 0 则只能说明“没有在时限内变空，或命令遇到其它执行错误”。如果需要把超时和更底层的执行错误严格区分，应结合系统日志、服务状态和后续设备检查，而不是凭一个非零值猜原因。

--timeout=0 是另一个常见陷阱：它会立即检查队列是否为空。它适合做轻量探测，不适合替代等待。对于“队列现在还没空，但允许它继续处理”的场景，应该使用一个大于 0 的预算，并把失败分支设计成可恢复动作。

高压启动链路中的取舍

把等待时间直接拉长，表面上能减少偶发的未就绪问题，却会把单个慢事件的成本传递给所有依赖这条启动链路的服务。尤其在多盘、热插拔设备或并行初始化环境中，全局队列可能包含与你的目标设备无关的事件。旧做法的问题不是“120 秒不够长”，而是把所有事件当成同一个业务前置条件。

更稳妥的架构是把等待拆成三层：先用短的全局队列等待保护启动预算；再对目标设备做明确的存在性、属性或服务级检查；最后为可恢复场景保留一次有限重试。这样付出的代价是脚本更长，需要维护判断日志，但可以把“udev 事件完成”和“业务设备可用”分开记录。

#!/usr/bin/env bash
set -u

# 第一层：只为全局 udev 队列设置有限等待，不承诺业务设备已可用。
if ! udevadm settle --timeout=10; then
    echo "udev queue is still busy after 10 seconds" >&2
    # 这里可按业务决定重试或终止，不能静默吞掉失败。
    exit 75
fi

# 第二层：把目标设备检查写成独立条件，避免用 settle 代替设备检查。
device_path="/dev/example-device"
if [ ! -e "$device_path" ]; then
    echo "target device is not present: $device_path" >&2
    # 设备不存在时，返回业务约定的可重试状态。
    exit 76
fi

# 第三层：只有通过前两层，才进入依赖设备节点的后续动作。
echo "udev queue is clear and target device exists"

几个容易把超时归错因的场景

第一，队列没有清空不一定等于某条规则写错。规则执行慢、设备驱动响应慢、事件持续涌入，都会让等待超过预算。此时应把队列等待日志与 systemd-udevd 状态、内核日志和具体设备状态放在同一时间窗口观察。

第二，队列清空也不等于应用层初始化完成。规则可能已经处理完，但挂载、网络配置、服务发现或业务探测仍未结束。如果后续动作依赖这些条件，应使用对应层级的检查，而不是继续增加 settle 的超时。

第三，udevadm trigger --settle 与单独的 udevadm settle 选择不同。在共享启动环境中，前者适合“我刚触发了一组事件，只等待这组”；后者适合“我需要确认当前队列整体安静”。范围越大，越要谨慎估算等待成本。

速查表：该怎么解释一次返回

排查清单

1. 记录实际调用的是单独的 settle 还是 trigger --settle。
2. 记录是否显式设置 --timeout，以及脚本总启动预算。
3. 保存退出码，不用标准输出是否为空代替判断。
4. 确认超时时段是否有持续事件、慢规则或驱动响应问题。
5. 独立检查目标设备节点、属性、挂载或服务状态。
6. 为失败分支选择可恢复重试、明确降级或终止后续动作，并把原因写入日志。

常见问题

udevadm settle 返回非零是不是设备一定不存在？

不是。它首先说明事件队列没有在指定时限内变空，设备不存在只是可能的后续现象之一。需要单独检查目标路径和设备属性。

把 timeout 调到 0 能不能避免启动变慢？

它只是即时检查，不能解决事件尚未完成的问题。若业务允许等待，应使用明确的大于 0 的预算；若不允许等待，就把非零结果当成可见的降级分支。

为什么 trigger --settle 成功后还要检查设备？

因为它证明的是本次触发事件已完成，不是挂载、网络或业务服务已经满足应用条件。设备和业务层仍应有自己的检查。

默认 120 秒适合所有启动脚本吗？

不适合。默认值只是工具的等待上限，脚本应按设备规模、启动预算和可恢复策略显式选择超时。

最终判断可以压缩成一句话：先看等待范围，再看显式超时，最后看退出码和目标设备的独立状态。这样处理 udevadm settle，既不会把全局队列误当成设备就绪信号，也不会因为一次非零返回就盲目重发或无限等待。