服务不与shutdown.target冲突的含义

服务不与shutdown.target冲突的含义

<总结>
我正在基于当前的 Debian 10 Buster 和内核 ntfsd;systemd v241 调整仅支持 NFSv4 的文件服务器。该nfs-kernel-server发行版中的软件包 systemd 脚本让我感觉有点奇怪。根据 systemd.service(5),包括其nfs-server.service本身在内的一些服务定义文件带有设置DefaultDependencies=no,因此该单元不会自动获得依赖项:Conflicts=shutdown.target

[使用DefaultDependencies=yes] [s] 服务单元将具有类型Conflicts=Before=的依赖关系 [...] shutdown.target。这确保在系统关闭之前,正常服务单元 [...] 被彻底终止。

与我在其他 systemd 自己的软件包中看到的不同,这两个软件包都没有明确提供。命令

systemctl show nfs-server.service | egrep '^(Want|Requ|Bind|Bound|Before|After|Confl)'

确认这确实是事实:不存在此类依赖关系。手册继续说道,

只有涉及早期启动或晚期系统关闭的服务才应禁用此选项。

而 NFS 服务器恰恰不是这样,因为它只有在网络完全启动后才能开始提供服务,并且应该在系统关闭时立即停止接受新请求并因负载过重而失效。

这不是软件包中具有类似设置的单一服务,但这个服务最让我担心。我正在云设置中推出单一用途的虚拟机,文件服务器可能拥有大量的 RAM(64-128G),所有这些都塞满了文件系统缓存,如 htop(1) 所示。由于这是一台文件存储机器,我无法用语言表达我多么希望服务器能够“在系统关闭之前干净地终止”,特别是考虑到我使用导出文件系统的 ext4 挂载选项data=writebacknobarrier¹ 牺牲了一些可靠性来换取性能。
</总结>

所以我的这个问题可以浓缩成一句话:

当系统实际关闭时,没有Conflicts=Before=依赖关系的systemd 服务会发生什么?shutdown.target


¹ 这是一个经过深思熟虑的工程权衡,根据云提供商的 SLA 和一系列性能测试的结果进行评估,与问题的本质完全无关。

相关内容