☰

进一步阅读

tag-icon • tag-icon systemd dependencies systemd-unit
进一步阅读

在这个例子systemd 单元文件的：

# systemd-timesyncd.service
...

Before=time-sync.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-sync.target

systemd-timesyncd.service应该开始前 time-sync.target。这定义了一个顺序依赖性。

但同时systemd-timesyncd.service 想要 time-sync.target。time-sync.target其亦是如此需求依赖

这种关系的用例是什么？为什么它们彼此之间没有冲突？

答案1

这种双重关系的用例类似于“提供”关系。systemd-timesyncd提供时间同步服务，因此它满足单元对 的任何依赖性time-sync.target。它必须在此之前启动，time-sync.target因为它对于任何依赖时间同步的服务都是必要的，并且它之所以需要，是time-sync.target因为任何依赖时间同步的单元都应该与服务一起启动systemd-timesyncd。

我认为这个误解来自于你对“想要”的理解。 systemd 中的“想要”关系不是依赖关系：systemd-timesyncd不需要time-sync发挥作用。这是一个“开始于”关系：它表示配置单元 ( systemd-timesyncd.service) 希望列出的单元 ( time-sync.target) 与其一起开始。

也可以看看systemd 中哪个服务提供 time-sync.target？

答案2

该机制的目的是确保可以建立排序关系，但是不生效除非有必要。

time-sync.target是一个订购里程碑。所有提供“时间同步”的服务都指定它们是Before，time-sync.target以便只有在“时间同步”生效后目标才准备就绪。所有需要“时间同步”才能在运行时生效的服务都指定它们After是time-sync.target.

如果后者也Wants与该目标有关系，那么他们就会总是最终被它排序，因为它总是包含在被排序的事物集合中。

在实际上没有具体的“时间同步”服务的情况下，这被视为次优； systemd 人员的想法是，在这种情况下这样的顺序不应该生效。相反，服务应该像time-sync.target不存在一样进行排序，允许其中一些服务更早地启动（如果这是没有里程碑的“自然”位置）。

解决方案是time-sync.target实际上不在那里。期望在时间同步可用后启动的服务不需要它。所以它不存在于有序事物集合中，如果只有那些服务已启动。仅当以下情况时才将其带入集合中：实际的“时间同步”服务启动，该服务（而不是客户端服务）具有Wants引入它的关系。

目标不一定是服务的集合。他们还可以订购里程碑。

在 systemd 和其他地方有相当多的这样的纯粹里程碑。 nosh 工具集的服务捆绑集合中的目标name-services是类似的纯订购里程碑。

进一步阅读

  • 乔纳森·德博因·波拉德 (2018)。system-control。 小吃指南。软件。

答案3

time-sync.target是系统中的一种标志，因此依赖于正确时间的服务不必依赖于 systemd-timesyncd、ntpd 等。

该Before条目告诉 systemd 启动 systemd-timesyncd，然后启动 time-sync.target （这仅用于排序）。告诉Wants它实际设置标志。

相关内容