实际上是否存在指定“After=suspend.target”的 systemd 单元的竞争条件

Question

在关于在 resume 时启动 anacron 的 Debian 错误报告中，有人声称由于 systemd 依赖项的工作方式，此代码段（为简洁起见而简化）可能会在挂起而不是在恢复时触发。我无法理解使用 systemd 文档和 systemd 附带的单元文件指示的竞争条件。

[Unit]
Description=Do something at resume
After=suspend.target

[Service]
ExecStart=/bin/do-something

[Install]
WantedBy=suspend.target

这篇文章的作者继续引用systemd-suspend.service，其中包含以下声明（再次精简为相关声明）

[Unit]
After=sleep.target
Requires=sleep.target

其次是声称两个不同的单元，两个排序之后sleep.target并行运行，因此这两个单元之间没有排序。我完全同意这一点，但据我所知，没有两个单位都依赖于sleep.target。中的声明systemd-suspend.service确保sleep.target在进入睡眠之前完全启动，因此所有依赖于的单元sleep.target都已启动。但是查看suspend.target（原始单元文件真正依赖的目标），我发现以下声明：

[Unit]
BindsTo=systemd-suspend.service
After=systemd-suspend.service

我将此文件理解为suspend.target仅在成功启动后才声明systemd-suspend.service成功启动。现在，systemd-suspend.service再次查看，我在该文件中找到以下声明：

[Service]
Type=oneshot
Exec=/lib/systemd/systemd-sleep suspend

据我了解，一次性服务在Exec命令完成之前不会进入“已启动”状态。因此，任何订购After此服务的东西在systemd-sleep完成之前都不能开始。最后，看一下 systemd-sleep，它包含一些字符串的魔法写入到/sys/power/state，它会阻塞直到系统恢复。这应该确保所有想要在之后启动的东西systemd-suspend.service确实在恢复之前没有启动。

我声称写入/sys/power/state块的原因是该写入由该文件的 sysfs 存储函数处理，该函数调用pm_suspend非休眠模式，而后者又调用enter_state（直接pm_suspend在同一源文件中之前），这显然不会在恢复之前返回。

Answer 1

你说得对; #124 帖子是错误的。

人们有时会写单位，这是一个问题WantedBy=sleep.target After=sleep.target。这将在睡觉前启动设备，然后不等他们完成就睡觉，这几乎肯定不是他们想要做的。很有可能，这就是发帖者的想法。

权威：基于类似的分析，我独立编写了一个这样的单元来在简历上运行 hdparm。它工作正常，正如帖子 #129中的回复所述。我的设备每次都能正确运行。我知道，因为如果我在没有它的情况下运行，我可以听到硬盘驱动器发出的咔哒声。早些时候，我能够识别出udev 中的一个错误，该错误导致我之前的解决方案不可靠，仅仅是因为我注意到听到了喀哒声。