☰

systemd-timesyncd：由于排序周期（dbus、sysinit）导致启动失败

tag-icon • tag-icon linux boot time ntp
systemd-timesyncd：由于排序周期（dbus、sysinit）导致启动失败

我在使用非常基本的 Rocky Linux 9 设置时遇到了困难，我的 systemd-timesyncd 单元在启动时不断失败。

以下是日志

Feb 12 18:22:17 bigpu systemd[1]: sysinit.target: Found ordering cycle on systemd-timesyncd.service/start
Feb 12 18:22:17 bigpu systemd[1]: sysinit.target: Found dependency on dbus.socket/start
Feb 12 18:22:17 bigpu systemd[1]: sysinit.target: Found dependency on sysinit.target/start
Feb 12 18:22:17 bigpu systemd[1]: sysinit.target: Job systemd-timesyncd.service/start deleted to break ordering cycle starting with sysinit.target/start

我没有改变 systemd-timesyncd、dbus 或 sysinit 的单位定义。不知道发生了什么。

谷歌搜索没有帮助。任何帮助表示感谢！

答案1

发生这种情况是因为 Rocky 9 中有一个奇怪的错误。我不确定它是否存在于原始 RHEL 9 或其他 RHEL 克隆中。主要原因在于以下行

After=systemd-sysusers.service dbus.socket

在文件“/usr/lib/systemd/system/systemd-timesyncd.service“。

Systemd-timesyncd 需要在“dbus.socket”启动后执行，而“dbus.socket”依赖于“sysinit.target”，而“sysinit.target”又依赖于“systemd-timesyncd”。所以，循环结束了。

需要删除“dbus.socket”才能解决问题，但是“systemctl edit systemd-timesyncd“不会有帮助。因为这个单位有一个名为”dbus-org.freedesktop.timesync1.service“这不会受到 systemd 覆盖的影响。

因此，您需要编辑文件“/usr/lib/systemd/system/systemd-timesyncd.service“手动从中删除所有关于“dbus.socket”的提及。然后运行“systemctl daemon-reload”以应用更改。

请注意，系统升级可能会导致 systemd 配置文件回滚到其默认值。因此请记住这个可能的缺点。

答案2

正如@Stanislav 所说：

因此，您需要手动编辑文件“/usr/lib/systemd/system/systemd-timesyncd.service”，从中删除所有关于“dbus.socket”的内容。然后运行“systemctl daemon-reload”以应用更改。

dbus 确实是罪魁祸首，但让我补充一点说明——由于编辑原始单元文件（在/usr/lib/systemd/) 一般是不鼓励的。

加：

请注意，系统升级可能会导致 systemd 配置文件回滚到其默认值。因此请记住这个可能的缺点。

我的方法解决了这个问题。


0。

（...）手动删除所有提及关于“dbus.socket” (...)

改变就足够了”之后=“声明中[单元]部分，因此它看起来像：

[Unit]
(...)
After=systemd-sysusers.service
(...)

代替 ”之后=systemd-sysusers.service dbus.socket“。


1.您可以使用“编辑基本服务”systemctl 编辑“ 使用 ”- 满的“修饰符：

systemctl edit --full systemd-timesyncd.service

请注意，如果没有“- 满的“修饰符新目录创建于/etc/systemd/系统/称为[我们修改后的服务].d和 ”覆盖配置文件“文件（包括我们的修改）。此类编辑在“systemctl status [我们的服务]“ 在下面 ”插入：“，如我的其中一台服务器中的以下实例所示：

[root@XXXX XXXX]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: disabled)
     Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
             └─override.conf
     Active: active (running) since Mon 2024-04-01 19:38:51 CEST; 51min ago
(...)

通过使用“- 满的“修饰符没有发生这样的变化，而是有一个我们原始服务的副本（来自/usr/lib/systemd/系统/) 创建于/etc/systemd/系统/. 实例（同一服务器，同一服务，只是带有“- 满的“现在使用的修饰符：

[root@XXXX XXXX]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/etc/systemd/system/systemd-timesyncd.service; enabled; preset: disabled)
     Active: active (running) since Mon 2024-04-01 20:36:35 CEST; 1s ago

正如你所见，没有“插入：“在服务状态中，单元文件的路径已经改变（我已经改变了之后=systemd-sysusers.service在单元文件中）。


2.现在到了最有趣的部分——解释为什么正常的服务编辑（没有“- 满的“修饰符）不起作用。
因此，当我们启用 timesyncd 服务（systemctl 启用 systemd-timesyncd.service) 两个链接 (快捷方式使用 Windows 语言；]) 的创建方式如下：

Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.

如果你ls -al /etc/systemd/system/你会发现它们确实存在。
现在 - 如果我们正常编辑服务，这些链接不会察觉到我们的修改（我们的“插入：“换句话说）——因为这些修改是在服务启动时读取/加载的，并且链接读取原始的、未修改的单元文件——导致

[ SKIP ] Ordering cycle found, skipping Network Time Synchronization

在我们的 boot.log 中。

但与“- 满的“修饰符我们创建一个完整的[修改的]单位文件的副本（/etc/systemd/系统/），现在由前面提到的链接读取（而不是原始单元文件），和- 它包含了我们的修改，因此我们的问题得到了解决。


3.这篇文章的目的是：强烈反对（我同意）编辑原始服务/单元文件（在/usr/lib/systemd/系统/)，所以我描述了正确的方法。而且——我有 10 分钟的空闲时间 ;]

@Stanislav 的回答仍然有效，我只是对其进行了一些说明。

相关内容