systemctl 显示未找到服务文件,即使 .service 文件存在

systemctl 显示未找到服务文件,即使 .service 文件存在

我遇到了一个奇怪的问题。我有一个服务文件来启动自定义应用程序。systemctl 命令显示 LOAD 未找到

resource-service-prod-prod.service 未找到活动正在运行 resource-service-prod-prod.service

但是文件显示在

ls -lrt /etc/systemd/system
lrwxrwxrwx  1 root root   96 Mar  5  2017 resource-service-prod.service -> /opt/app/daps-prod/resource-service/bin/resource-service-prod-prod.service

服务状态显示为正在运行,但已加载:未找到(原因:没有此文件或目录)

sudo service resource-service-prod status
Redirecting to /bin/systemctl status resource-service-prod.service
● resource-service-prod-prod.service
   Loaded: not-found (Reason: No such file or directory)
   Active: active (running) since Thu 2018-12-20 06:40:37 CST; 3 weeks 0 days ago
 Main PID: 12888 (node)
   CGroup: /system.slice/resource-service-prod-prod.service
           ├─12888 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12923 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12924 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12930 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12936 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12942 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12943 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12949 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12960 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12961 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12972 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           ├─12978 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js
           └─12984 /usr/bin/node /opt/app/daps-prod/resource-service/source/app.js

应用程序在发出服务停止时停止,但在尝试重新启动时,它不会(因为找不到文件)。执行systemctl daemon-reload有助于重新启动服务,并且服务文件显示为已加载。知道为什么会出现这种行为吗?

实际的服务文件位于单独的挂载上,并且它是一个符号链接/etc/systemd/system

答案1

我知道这已经是几个月前的事了,但为了记录起见,还要检查一下服务的配置文件。您可能会收到此消息,因为未找到依赖单元。Systemd 似乎没有在错误消息中提供足够的细节来区分您正在启动的主单元和依赖单元。有时它会在启动时解决这些问题,然后如果您手动执行,它会失败,这非常令人抓狂。

答案2

可能是服务文件在服务运行时被移走了。您可能需要运行systemctl daemon-reload。当然,验证文件/opt/app/daps-prod/resource-service/bin/resource-service-prod-prod.service是否确实存在。

[root@storage system]# systemctl status smb.service
● smb.service - Samba SMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
...
[root@storage system]# systemctl daemon-reload
[root@storage system]# systemctl status smb.service
● smb.service
   Loaded: not-found (Reason: No such file or directory)
...
[root@storage system]# ln -s /opt/smb.service /usr/lib/systemd/system/smb.service
[root@storage system]# systemctl status smb.service
● smb.service
   Loaded: not-found (Reason: No such file or directory)
...
[root@storage system]# systemctl daemon-reload
[root@storage system]# systemctl status smb.service
● smb.service - Samba SMB Daemon
   Loaded: loaded (/opt/smb.service; enabled; vendor preset: disabled)

答案3

我在 Amazon Linux 上遇到了类似的问题。

以下对我有用

  • 我没有直接在中创建服务文件/etc/systemd/system/multi-user.target.wants/,而是在中创建了服务文件/usr/lib/systemd/system/,例如/usr/lib/systemd/system/abc.service
  • 然后我创建了一个链接 - ln  -sf /usr/lib/systemd/system/cerncshnbdr01-abc.service /etc/systemd/system/multi-user.target.wants/abc.service
  • 然后我就可以启用该服务了 -systemctl enable abc.service

答案4

我遇到过类似的问题,.service 位于同一磁盘的第二个分区上,运行良好,但重启后我总是收到未找到消息。我猜第二个分区在启动后延迟了几毫秒。

解决方案是将 .service 复制到系统分区(/etc/)并从那里安装。

知道使用 systemd 的生产服务器会如此脆弱真是太疯狂了。从那时起,我就转向了 Supervisord,再也没有回头。

相关内容