主页 / unix / 问题 / 751129
Accepted
Daniel
Asked: 2023-07-10 22:15:21 +0800 CST

udev: hwclock 设置失败？

  • 772

“/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”）时，它会正确设置时间。

udev

1 个回答

  1. Best Answer

    现代systemd-udevd运行与

    CapabilityBoundingSet=~CAP_SYS_TIME CAP_WAKE_ALARM

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

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

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

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

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

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

    • 2

相关问题