我已经用它systemd-timesyncd作为我的系统计时器好几年了。我运行的是 Debian衍生物被称为树莓派对于我的树莓派。我对 SNTP 客户端非常满意systemd-timesyncd，但想尝试chronyd在离网应用程序中使用。
以下命令可用于列出配置systemd-timesyncd：
$ systemctl cat systemd-timesyncd
在巴斯特，此清单中有一段代码，systemd-timesyncd如果发现安装了另一个计时服务（NTP 守护进程），则可以“自行原谅”：
# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService
在某个点发布后巴斯特（同时发布靶心??)，对上述方案进行了修改；如果发现其他计时器，该命令systemctl cat systemd-timesyncd不再包含任何限制或禁止启动的引用。systemd-timesyncd
有谁还记得这个变化的历史吗？更重要的是，systemd-timesyncd如果发现安装了另一个计时守护进程，是否仍然会抑制其启动？这是在哪里/如何完成的？
答案1
该systemd-timesyncd服务本身不再检查冲突。相反，冲突是通过systemd-timesyncd在自己的包中处理的，与其他授时服务包冲突：因此现在不可能有两个时间服务器已安装（使用 Debian 软件包）。
更详细地说，其工作方式是systemd-timesyncd包有一个Conflicts: time-daemon条目。time-daemon是所有时间守护进程提供的虚拟包，并且它们都与它冲突，因此一次只能安装一个时间守护程序（包不能与自身冲突，因此明显的自我冲突不是问题）。这是 Debian 中的标准机制，用于确保提供提供给定功能的集合中的单个包。包拆分很重要，因为无法在systemd包本身上定义此类包冲突。
这可能看起来更脆弱，因为它不处理手动安装的时间服务器。然而，这些无论如何都不应该进入/usr/sbin，所以之前的方案也无法处理它们。最重要的是，自动启用和禁用时间守护进程被证明是不可靠的，并且当时似乎不可能解决这个问题。