有多种原因必须在生产中重命名 systemd 服务。例如：
- 更好地将其与新产品区分开来
- 因为你老板订的
- 因为遗留脚本
- ...
假设一个新的通用服务创建/etc/systemd/system/foo.service并启用和启动如下：[1]
systemctl daemon-reload
systemctl enable --now foo
然后，您可能希望将其从 重命名foo.service为bar.service而不以任何方式影响相关进程。
在正常情况下，您可以执行以下操作：
mv foo.service bar.service
systemctl daemon-reload
systemctl disable foo
systemctl enable bar
然后你获得：
systemctl status foo：runningnot-founddisabledsystemctl status bar：not-runningenabled
因此，您可能需要修复：
systemctl stop foo
systemctl start bar
或者重新启动。但是在生产环境中这是不可行的，因为您不想停止应用程序进行此类更改。此外，重新启动计划在数月或数年后进行。同时，bar在停止未找到的运行之前，长时间保持不应该错误启动的停止服务是有风险的foo。
简而言之。您将使用什么方法来重命名生产中的 systemd 服务？
理想的条件是让这两种服务向后兼容。因此，停止foo也停止bar，反之亦然。
可能有一些我不知道的更好的方法，但这是一种解决方法，主要是在您有机会重新启动服务之前为您提供所需的东西：
systemctl daemon-reload）的所需新名称创建符号链接。Systemd将单元的符号链接视为别名而不是单独的单元，这意味着两个名称现在将引用同一个单元（相同的状态，相同的一切）。