☰

Файл службы существует, но не найден 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 (Core)
  • Системная версия: 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

Была похожая проблема, мы используем podman без прав root на centos7.

Контейнер не был запущен после перезагрузки, службы не были найдены. Но до перезагрузки службы были включены и присутствовали в /etc/systemd/system. Службы были созданы через syslink ln -s из /home/user в /etc/systemd

При запуске после перезагрузки Systemctl status nameOfService.serviceвозвращается сообщение «Unit servicename.service не найден».

При запуске systemctl daemon-reloadслужба снова присутствует.

Одним из возможных решений является создание системной ссылки ln -s из /root/ в /etc/systemd/system — после перезагрузки ваша служба все еще будет существовать.

Лучшее решение

  • Создайте свою собственную службу, которая выполняет daemon-reload и запускает вашу службу

Создайте скрипт startServiceOnBoot.sh с daemon-reload и запустите свою службу

    #!/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.

Я пробовал After= и .timer с сервисами в systemd, но безуспешно. За отладку винить $systemd-analyze

Связанный контент