☰

udev: hwclock 设置失败？

tag-icon • tag-icon udev
udev: hwclock 设置失败？

“/usr/lib/udev/hwclock-set”中有一个文件：

它应从 RTC 设置正确的日期/时间，但有一个障碍：

if [ -e /run/systemd/system ] ; then
    exit 0
fi
/shin/hwclock ....

现在，当 udev 运行 hwclock 规则时，上述文件夹已经存在，因此脚本将退出，而不设置系统时间。

这个条件背后的想法是什么？

此外，它还阻止 udev 规则和 systemd 服务设置系统时间（通过此脚本）。

它让我疯狂。没有 udev 规则或 systemd 服务可以处理此障碍。

此外2：当我取消注释“exit”并且udev规则尝试运行此脚本时，所有“hwclock”调用都返回1（错误）。

当我手动运行此脚本（使用未注释的“exit”）时，它会正确设置时间。

答案1

现代systemd-udevd运行与

CapabilityBoundingSet=~CAP_SYS_TIME CAP_WAKE_ALARM

在其服务文件中。这意味着由 udev 规则启动的进程无法操纵系统时间，因为该CAP_SYS_TIME功能已被排除在udevd其子进程之外。

另一方面，systemd它本身应该在启动过程的早期（基本上是在systemd启动时）从（第一个）RTC 处理系统时钟设置。为了成功实现这一点，内核应该内置硬件 RTC 的驱动程序，而不是作为模块。

或者，如果您的硬件有多个 RTC，则您希望用于系统时间的 RTC 驱动程序应该是内置的，而其他任何驱动程序都应作为可加载模块。这应该确保正确的 RTC 被检测为rtc0，这显然是自动用于systemd设置系统时间的 RTC。

systemd显然，如果您的硬件有多个 RTC 并且您要使用的 RTC 没有被内核检测为第一个，则这种行为可能会导致一些意外，如下所示你最近的另一个问题。

当然，如果您正在处理具有多个 RTC 的嵌入式系统，并且需要 RTC 驱动程序作为模块，那么通过从文件中删除该行并从文件中删除阻塞条件udev，允许其子进程操纵系统时间可能是一个有效的权衡。文件。CapabilityBoundingSet=systemd-udevd.service/usr/lib/udev/hwclock-set

新的“标准设置”的主要优点似乎是所有日志都应该有正确的时间戳一旦systemd开始就理所当然。如果您进行更改以让 udev 规则在加载适当的 RTC 驱动程序模块后处理设置系统时钟，则可能会在早期启动时记录一些带有不正确时间戳的消息，并且在阅读日志时需要记住这一点。

相关内容