☰

El archivo de servicio existe pero systemd no lo encuentra

tag-icon • tag-icon linux systemd
El archivo de servicio existe pero systemd no lo encuentra

Creé un archivo de servicio systemd y lo coloqué en /etc/systemd/system/anfragen-3dkonfig-mapper.service. Ejecuté systemctl daemon-reloady systemctl daemon-reexecreinicié el sistema.

  • systemctl enable anfragen-3dkonfig-mapperresultados en

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

  • systemctl start anfragen-3dkonfig-mapperresultados en

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

  • ls -lh /etc/systemd/system/anfragen-3dkonfig-mapper.servicesalidas

    -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.servicetiene un código de salida de 0 y no imprime ningún resultado.

  • mountmuestra

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

  • No hay otros soportes que se toquen /usro /etc.

  • El contenido del archivo de servicio es:

    [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

  • Todos los comandos anteriores se ejecutaron como rootusuario.

  • Sistema operativo: CentOS Linux versión 8.0.1905 (Núcleo)
  • Versión del sistema: 239
  • Núcleo de 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))
  • Recuerdo vagamente haber tenido un problema similar con otro archivo de servicio hace algunos meses que mágicamente comenzó a funcionar después de unas horas de hurgar y cambiar el nombre del archivo de servicio de un lado a otro.

Me interesan dos cosas:

  • ¿Cómo se puede depurar un problema así?
  • ¿Lo que está mal?

Respuesta1

Como lo insinuó @JdeBP, las etiquetas incorrectas de los archivos SELinux son la razón del comportamiento. El .carácter en el resultado de lsindica que hay un contexto de seguridad establecido para el archivo. ¡Así que esté atento a .la lssalida!

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

-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

Se puede ver que el otro archivo de servicio tiene la systemd_unit_file_tetiqueta, mientras que el servicio roto no. Esto se puede solucionar con restorecon anfragen-3dkonfig-mapper.service. Después de esto, las etiquetas quedan de la siguiente manera:

-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 ahora se comporta como se esperaba.

Respuesta2

-rw-r--r--.

Las restricciones de SELinux le están complicando la vida.

Respuesta3

Pasé una hora investigando este problema después de mover algunos de los archivos del servicio. El enlace simbólico /lib/systemd/systemapuntaba al archivo correcto, pero /etc/systemd/systemno (su destino ya no existía). Eliminé este enlace simbólico ofensivo (roto), lo reemplacé por el correcto y funcionó.

Respuesta4

Tuve un problema similar, usamos podman sin raíz en centos7.

El contenedor no se inició después del reinicio, no se encontraron los servicios. Pero antes de reiniciar, los servicios estaban habilitados y presentes en /etc/systemd/system. Los servicios se crearon a través de syslink ln -s desde /home/user a /etc/systemd

Cuando lo ejecuta después de reiniciar Systemctl status nameOfService.service, devuelve "No se pudo encontrar la unidad servicename.service".

Cuando ejecuta systemctl daemon-reloadel servicio vuelve a estar presente.

Una posible solución es crear un enlace del sistema ln -s desde /root/ a /etc/systemd/system; después de reiniciar, su servicio seguirá existiendo.

Mejor solución

  • Cree su propio servicio que ejecute daemon-reload e inicie su servicio

Cree el script startServiceOnBoot.sh con daemon-reload e inicie su servicio

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

Hacer ejecutable el script shchmod +x startServiecOnBoot.sh

Crea tu servicio /etc/systemd/system/serviceStarter.service

[Unit]
Description=Daemon Reloader
...

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

[Install]
WantedBy=multi-user.target

Habilite el servicio al arrancar. systemctl enable serviceStarter.serviceTambién puede verificar si al iniciar su nuevo servicio, serviceStarter.service, también se inicia nameOfService.service.

Probé After= y .timer con servicios en systemd pero no tuve éxito. Para depurar la culpa de $systemd-analyze

información relacionada