systemd 将服务添加到 multi-user.target.wants 文件夹中仅用作符号链接

Question

我一直在添加一些 systemd 服务。我开始时我的服务是来自以下方面的符号链接：

/etc/systemd/system/multi-user.target.wants/myservice.service -> /home/myservice.service

这似乎工作正常。但是如果我删除符号链接并使其成为一个conrete文件，那么该服务不会加载（systemctl daemon-reload找不到它）。

但是，如果我将服务移入，/etc/systemd/system/myservice.service则它可以正常工作。

因此，对于在 multi-user.target.wants 中工作的服务，它似乎需要是一个符号链接。这是为什么？有没有办法解决这个问题？

我../myservice.service之前在 multi-user.target.wants 中看到过符号链接......我猜我已经偶然发现了原因！？

Answer 1

.wants/和.requires/目录中只允许使用符号链接。按照习惯，将符号链接到本单位的实际文件进行/etc/systemd/system/，/usr/lib/systemd/system/或者由其他单位目录之一。但是 systemd 不太关心符号链接目标。（符号链接的目标目录被完全忽略。符号链接目标的最后一部分被检查，如果目标名称与符号链接名称不匹配，较新的 systemd 将发出警告，但仍会接受它）。符号链接的存在表明需要创建 Wants 或 Requires 依赖项。

该.wants/和.requires/目录是申报依赖的机制。但是要真正加载单元，systemd 需要找到单元文件。它需要在目录（之一/etc/systemd/system/，/usr/lib/systemd/system/等等）。

您可能会对较旧的 systemd 会遵循来自.wants/或 的单元符号链接.requires/并加载单元文件的事实感到困惑。这是有问题的，有两个原因：第一个是 systemd 对目录具有优先级顺序，并且它应该将单元文件加载到具有最高优先级的目录中。但是符号链接可能指向优先级较低的目录中的单元文件。为了保持一致，systemd 必须忽略符号链接目标，并按顺序搜索目录。第二个原因是符号链接可能指向搜索路径之外的文件。如果 systemd 允许加载这样的单元，这些单元可以作为另一个单元的依赖项加载，但是当要求直接加载单元时，systemd 将无法找到它。较新的 systemd 从不遵循此类符号链接。

上一段中的第二个原因也是 systemd 不允许在.wants/or中存在真实文件的原因.requires/：该单元只能作为另一个单元的依赖项加载，而不能直接加载。

有两种正确的处理方法：

1. 将单元文件移动到单元目录之一，例如/etc/systemd/system/myservice.service，并从multi-user.target.wants/.
2. 将单元文件保存在其他地方，例如~/myservice.service，并从单元目录之一符号链接到它，例如/etc/systemd/system/myservice.service，从multi-user.target.wants/.

另请参阅systemctl link和systemctl enable可以为您创建这些符号链接。