☰

服務文件存在，但 systemd 找不到

tag-icon • tag-icon linux systemd
服務文件存在，但 systemd 找不到

我建立了一個 systemd 服務文件並將其放入/etc/systemd/system/anfragen-3dkonfig-mapper.service.我運行systemctl daemon-reload並systemctl daemon-reexec重新啟動系統。

  • systemctl enable anfragen-3dkonfig-mapper結果是

    Failed to enable unit: Unit file anfragen-3dkonfig-mapper.service does not exist.

  • systemctl start anfragen-3dkonfig-mapper結果是

    Failed to start anfragen-3dkonfig-mapper.service: Unit anfragen-3dkonfig-mapper.service not found.

  • ls -lh /etc/systemd/system/anfragen-3dkonfig-mapper.service輸出

    -rw-r--r--. 1 root root 440 Mar 19 12:08 /etc/systemd/system/anfragen-3dkonfig-mapper.service

  • cd /root && systemd-analyze verify anfragen-3dkonfig-mapper.service退出代碼為 0 且不列印任何輸出。

  • mount節目

    /dev/sda2 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

  • 沒有其他坐騎接觸/usr或/etc。

  • 服務文件的內容是：

    [Unit]
Description=Anfragen 3D Konfigurations Mapper Service
After=network.target

[Service]
Restart=always
ExecStartPre=-/usr/bin/podman stop anfragen-3dkonfig-mapper
ExecStartPre=-/usr/bin/podman rm anfragen-3dkonfig-mapper
ExecStart=/usr/bin/podman run --rm --name anfragen-3dkonfig-mapper-app -p 10010:10000 anfragen-3dkonfig-mapper-app:0.0.1
ExecStop=/usr/bin/podman stop anfragen-3dkonfig-mapper

[Install]
WantedBy=multi-user.target

  • 以上所有指令均以使用者身分執行root。

  • 作業系統：CentOS Linux 版本 8.0.1905（核心）
  • 系統版本：239
  • Linux核心：Linux version 4.18.0-80.11.2.el8_0.x86_64 ([email protected]) (gcc version 8.2.1 20180905 (Red Hat 8.2.1-3) (GCC))
  • 我依稀記得幾個月前另一個服務文件也遇到了類似的問題，經過幾個小時的探索和來回重命名服務文件後，它神奇地開始工作。

我對兩件事感興趣：

  • 如何調試這樣的問題？
  • 怎麼了？

答案1

正如 @JdeBP 所暗示的，錯誤的 SELinux 檔案標籤是導致該行為的原因。.輸出中的字元表示ls該檔案已設定安全上下文。所以要注意.輸出中的ls！

cd /etc/systemd/system && ls -lhZ some-other-service.service anfragen-3dkonfig-mapper.service印刷

-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0        440 Mar 19 12:08 anfragen-3dkonfig-mapper.service
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 457 Feb 24 11:42 some-other-service.service

可以看到，另一個服務文件有該systemd_unit_file_t標籤，而損壞的服務則沒有。這可以透過 修復restorecon anfragen-3dkonfig-mapper.service。之後標籤如下圖所示：

-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 440 Mar 19 12:08 anfragen-3dkonfig-mapper.service
-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 457 Feb 24 11:42 some-other-service.service

systemd 現在的行為符合預期。

答案2

-rw-r--r--.

SELinux 限制使您的生活變得複雜。

答案3

在移動了一些服務文件後，我花了一個小時來解決這個問題。中的符號連結/lib/systemd/system指向正確的文件，但中的符號連結/etc/systemd/system不是（其目標不再存在）。我刪除了這個有問題的（損壞的）符號鏈接，用正確的符號鏈接替換它，並且它起作用了。

答案4

有類似的問題，我們在centos7上使用rootless podman。

重啟後容器未啟動，未找到服務。但在重新啟動之前，服務已啟用並存在於 /etc/systemd/system 中。服務是透過 syslink ln -s 從 /home/user 到 /etc/systemd 建立的

當您重新啟動後運行時，Systemctl status nameOfService.service它會返回“無法找到單位服務名稱。服務”。

當您執行該服務時systemctl daemon-reload，該服務會再次出現。

一個可能的解決方案是建立一個從 /root/ 到 /etc/systemd/system 的 syslink ln -s - 重新啟動後您的服務仍然存在。

更好的解決方案

  • 建立您自己的服務來執行 daemon-reload 並啟動您的服務

使用 daemon-reload 建立 startServiceOnBoot.sh 腳本並啟動服務

    #!/bin/bash 
    sudo systemctl daemon-reload    
    sudo systemctl start nameOfService.service

使 sh 腳本可執行chmod +x startServiecOnBoot.sh

建立您的服務 /etc/systemd/system/serviceStarter.service

[Unit]
Description=Daemon Reloader
...

[Service]
ExecStart=/home/user/startServiecOnBoot.sh
...

[Install]
WantedBy=multi-user.target

在啟動時啟用服務systemctl enable serviceStarter.service您也可以檢查啟動新服務 serviceStarter.service 是否實際上也啟動了 nameOfService.service 。

我在 systemd 中嘗試使用 After= 和 .timer 服務，但沒有成功。用於調試 $systemd-analyze Blame

相關內容