这确实是个值得理顺的小问题——保持安装路径的一致性不仅看着舒服，还能减少后续维护的麻烦，尤其你们现在大多是源码直接安装的场景。我来给你几个实用的解决办法：

方法一：全局配置systemd加载/usr/local下的单元文件 #

systemd默认不会主动搜索/usr/local/lib/systemd/system路径，但我们可以通过drop-in配置文件来扩展它的单元搜索路径，这种方式比直接修改主配置文件更稳妥，不会被系统更新覆盖：

1. 创建自定义配置目录（不存在则新建）：

   mkdir -p /etc/systemd/system.conf.d/
   

2. 在该目录下新建配置文件99-local-unit-path.conf（文件名以99开头是为了保证最后加载，覆盖默认配置）：

   [Manager]
   UnitPath=/usr/local/lib/systemd/system:/usr/lib/systemd/system:/etc/systemd/system:/run/systemd/system
   

   把/usr/local/lib/systemd/system放在最前面，确保systemd优先搜索这个路径的单元文件，后面保留默认路径保证系统服务不受影响。

3. 重新加载systemd配置让修改生效：

   systemctl daemon-reload
   

之后你就能把源码安装软件的systemd单元文件统一放到/usr/local/lib/systemd/system下，和其他文件的安装路径保持一致，不用再硬编码到/usr/lib/systemd/system了。

方法二：处理自定义前缀（比如/opt/MySoftware）的场景 #

如果以后有软件安装到自定义前缀路径，比如/opt/MySoftware/lib/systemd/system，可以用两种方式处理：

• 把这个路径也加到上面的UnitPath配置里，和/usr/local的路径放在一起；
• 或者用systemctl link命令手动链接单元文件到systemd默认搜索路径：

  systemctl link /opt/MySoftware/lib/systemd/system/your-service.service
  

  链接完成后同样需要执行systemctl daemon-reload让systemd识别。

额外小提示 #

如果只是临时测试自定义路径下的单元文件，也可以直接用绝对路径启用服务：

systemctl enable --now /usr/local/lib/systemd/system/your-service.service

不过全局配置路径的方式显然更适合你们的构建工具统一安装流程。

备注：内容来源于stack exchange，提问作者Chris Robison