如何让 systemd 在启动时不启动系统服务？

Question

我不想删除该服务，我只想避免它在启动时启动。我仍然需要稍后手动启动它的选项（使用systemctl start <service>命令）。

我尝试使用systemctl disable <service>. 它不起作用，因为它删除了服务。

还有另一种可能。在其服务文件中，

[Install]
#WantedBy=multi-user.target

可以被注释掉（然后，systemctl daemon-reload）。它适用于我自己的服务，因为他们的服务文件是我写的。

但是，属于分发的服务文件位于/lib/systemd/system. 该目录中的文件由操作系统管理，即它们将被更新覆盖，系统的其他部分可能假定这些文件未修改，等等。简单地编辑系统文件/etc是一种不好的做法，我不想这样做。我不想在我的/lib.

该怎么办？

Answer 1

systemctl disable是这样做的正确方法；它仍然允许手动启动一个单元，即使它没有出现在systemctl --all的输出中——要列出所有可启动的单元，你应该运行systemctl list-unit-files。要使单元无法启动，您需要使用mask它。

$ sudo systemctl stop unbound
$ sudo systemctl status unbound
? unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2019-05-03 13:12:41 CEST; 5s ago
     Docs: man:unbound(8)
 Main PID: 5320 (code=exited, status=0/SUCCESS)

$ sudo systemctl disable unbound
$ sudo systemctl status unbound
? unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:unbound(8)

$ sudo systemctl start unbound
$ sudo systemctl status unbound
? unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-05-03 13:13:14 CEST; 1s ago
     Docs: man:unbound(8)
  Process: 30513 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 30518 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
 Main PID: 30525 (unbound)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/unbound.service
           ??30525 /usr/sbin/unbound -d

如果你真的想，你可以通过在 中/lib添加文件来覆盖系统提供的服务/etc，并更改它们所需的目标；systemctl edit yourunit会做正确的事情：它会打开一个编辑器，允许您只覆盖您关心的设置，并将结果存储在正确的位置，作为覆盖“片段”。对系统提供的服务中的非覆盖设置所做的更新（例如通过包升级）将被透明地考虑在内。

Answer 2

我没想到会写出这么长的答案，但您似乎一直在使用 systemd 尝试不同的事情，并且我认为您对它的机制更感兴趣，而不仅仅是简单地输入一次魔术命令并忘记它的存在。我可以谈论 systemd 很多很多！

\n

我。

\n

当您作为管理员想要禁用某项服务启动或启用时，从管理的角度来看，斯蒂芬·基特的回答非常好且详尽（我很高兴对它进行投票） 。正如 systemd 文档 v241 所说（请参阅 参考资料man 5 systemd.unit）：

\n

\n

如果单元文件为空（即文件大小为0）或符号链接到/dev/null，则不会加载其配置，并且加载状态为“屏蔽”，并且无法激活。使用此方法可以有效地完全禁用某个单元，甚至无法手动启动它。

\n

\n

systemctl mask正是这样做的：它创建一个与下面的单元同名的符号链接/etc，并将服务文件符号链接到/dev/null. 由于 systemd 首先查找/etc（该顺序在同一手册中的第一行中给出）并找到指定的单元，因此它发现该单元被屏蔽。它是为此而设计的，如果您想阻止某项服务被启用和启动，请使用它。这是最简单的单命令解决方案，重启后仍然有效。能简单做的事情就保持简单。

\n

二.

\n

但是，如果您正在设计一组相互依赖的服务，那么以系统构建者而不是管理员的角色，使用命令声明服务不可启动或不可停止是有意义的systemctl，同时仍然允许其他机制（套接字、dbus）等）以按需启动。为此，systemd 有设置，也在同一手册中进行了描述：RefuseManualStart=和RefuseManualStop=：

\n

\n

采用布尔参数。如果为 true，则该单元只能间接激活或停用。在这种情况下，用户请求的显式启动或终止将被拒绝，但是，如果它作为另一个单元的依赖项而启动或停止，则启动或终止将成功。这主要是一种安全功能，以确保用户不会意外地激活不打算显式激活的单元，也不会意外地停用不打算停用的单元。这些选项默认为 false。

\n

\n

您可以启用此类服务​​，但它将拒绝启动systemctl start（或停止，对于其他设置），以防止操作员错误。

\n

三．

\n

[Install]根据您在服务文件中注释该部分的想法建议，需要详细说明一点：

\n

[Install]\n#WantedBy=multi-user.target\n

\n

如果服务随系统一起提供，也就是说，当单元文件位于层次结构下的某个位置时，请不要这样做/lib！升级要么默默地覆盖它，要么要求您手动干预以合并更改。systemd 对此有更好的机制。按照惯例（对于系统服务），systemd 下的目录/etc是“您的”，但下面的目录/lib属于发行版。

\n

例如，如果您想WantedBy=从该[Install]部分中删除该子句，则应该使用 systemd 适当的机制对服务进行一些调整：使用命令sudo systemctl edit servicename.service。systemd 将为您打开一个编辑器，最初该文件将为空。

\n

systemd 的下一个有用的属性是，当关键字值是一个列表（例如WantedBy）时，为其分配一个空字符串会重置列表（不同版本中存在不一致的情况，但大多数情况下它是有效的。在我们的例子中确实如此）。在编辑器中，您添加两行（这只是您尝试过的概念的详细说明，但尚未完全达到可行的解决方案；我们已经知道您将通过屏蔽实现您想要的效果）：

\n

[Install]\nWantedBy=\n

\n

这会将WantedBy列表重置为空。如果您想添加另一个依赖项，只需添加具有相同键的另一行（WantedBy=another.service在我们考虑不周的示例中是另一个 ）。幕后实际发生的情况是，systemd 在 i.\xc2\xa0e 下创建一个覆盖文件/etc。在您的机器所有者的目录中，并承诺永远不会碰它。假定默认目录布局为 .systemd 创建的文件被命名为/etc/systemd/system/servicename.service.d/override.conf. 这里的servicename.service部分正是您要覆盖的单元名称。systemd 尊重这个新子目录中与模式匹配的所有文件*.conf，因此可以不仅仅是override.conf; 只需注意它们将按名称的字典顺序应用，最低的在前（如ls -1 *.conf | LC_ALL=C sort所示）。

\n

虽然在您的情况下这不是一个正确的机制，正如 Peter 已经在后续评论中回答的那样，但有时当您想要添加环境变量，甚至解决错误\xc2\xb9 时，它会很有帮助，例如

\n

$ cat /etc/systemd/system/systemd-remount-fs.service.d/override.conf\n# Workaround for the systemd bug #14603: remount-fs and growfs@\n# race, so that the latter may fail because the root fs is still\n# readonly. This dependency ensures that the remount happens first.\n[Unit]\nBefore=systemd-growfs@-.service\n

\n

systemctl show 您可以使用myunit.service验证您的覆盖是否已合并到单元配置中。它的输出非常详细，所以使用 grep：

\n

$ systemctl show systemd-remount-fs.service | grep ^Before=\nBefore=systemd-update-utmp.service [...] systemd-growfs@-.service [...]\n

\n

这不是世界上最清晰的示例，因为该行很长；我在标记处删除了大部分内容[...]，但您可以systemd-growfs@-.service在列表中找到。即使在尝试不同的启动/停止/启动/休眠和其他方案之前，最好始终验证配置更改是否确实已纳入设备的组合设置中。拼写错误时有发生。

\n

四．

\n

当然，您可以调整任何类型的单元，而不仅仅是服务：计时器、套接字、挂载等。甚至在目录下动态生成的单元文件也/run尊重这些调整。例如，尽管在以下情况下/opt使用常规挂载，但 systemd 会在 RAM 文件系统目录中为其/etc/fstab生成一个临时单元。这个临时单元可以完美地识别 中指定的附加内容。顺便说一句，它想要的服务是正确使用和的一个示例：它应该仅在文件系统安装和卸载时完成其工作，如果手动启动，则会挂起或吐出错误。更糟糕的是，如果已经手动启动它，它就不会在文件系统安装后立即启动！opt.mount/run/systemd/systemWants=/etc/systemd/systemRefuseManualStartRefuseManualStop/opt/opt

\n

BindsTo=opt.mount该服务还通过指定和来显示“强绑定”模式After=opt.mount。引用 systemd.unit(5) 手册，在“[UNIT] SECTION OPTIONS/BindsTo=”下，将我的添加放在括号中以使语言更容易理解：

\n

\n

当在同一单元[,]上与 After= 结合使用时，BindsTo= 的行为甚至更强。在这种情况下，[该单元所]绑定的单元[必须]处于活动状态，该单元也[并保持]处于活动状态。

\n

\n

这里的含义是，该单元在停止之后启动，在opt.mount停止之前停止，以严格的步调。

\n

** **

\n

systemd 是一个庞大、强大且灵活的系统，如果您正在以尽可能最佳的方式调整系统，那么man当您对其他事情感到厌倦时，阅读 Web 上的文档肯定是有益的。

\n\n

\xc2\xb9 该错误已在一年多前修复，并且该修复已进入 systemd 245 版本，但由于我正在聚集各种发行版，并且有时会从旧映像中汇总虚拟机，所以我\必须保留一段时间。Debian 10 有 systemd 的前缀 v241；仅 Debian 11 附带 v247。生产系统升级缓慢，因此解决方案是再保留几年。

\n