☰

O arquivo de serviço existe, mas não foi encontrado pelo systemd

tag-icon • tag-icon linux systemd
O arquivo de serviço existe, mas não foi encontrado pelo systemd

Eu criei um arquivo de serviço systemd e coloquei-o no formato /etc/systemd/system/anfragen-3dkonfig-mapper.service. Executei systemctl daemon-reloade systemctl daemon-reexecreiniciei o sistema.

  • systemctl enable anfragen-3dkonfig-mapperresulta em

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

  • systemctl start anfragen-3dkonfig-mapperresulta em

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

  • ls -lh /etc/systemd/system/anfragen-3dkonfig-mapper.servicesaídas

    -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.servicetem um código de saída 0 e não imprime nenhuma saída.

  • mountmostra

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

  • Não há outras montagens tocando /usrou /etc.

  • O conteúdo do arquivo de serviço é:

    [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 os comandos acima foram executados como rootusuário.

  • Sistema operacional: CentOS Linux versão 8.0.1905 (núcleo)
  • Versão do sistema: 239
  • Kernel 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))
  • Lembro-me vagamente de ter tido um problema semelhante com outro arquivo de serviço há alguns meses, que magicamente começou a funcionar depois de algumas horas fuçando e renomeando o arquivo de serviço.

Estou interessado em duas coisas:

  • Como alguém depura tal problema?
  • O que está errado?

Responder1

Conforme sugerido por @JdeBP, rótulos de arquivo SELinux errados são a razão do comportamento. O .caractere na saída lsindica que há um contexto de segurança definido para o arquivo. Portanto, fique atento à .saída ls!

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

-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

Pode-se observar que o outro arquivo de serviço possui o systemd_unit_file_trótulo, enquanto o serviço quebrado não. Isso pode ser corrigido com restorecon anfragen-3dkonfig-mapper.service. Depois disso, os rótulos ficam da seguinte forma:

-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 agora se comporta conforme o esperado.

Responder2

-rw-r--r--.

As restrições do SELinux estão tornando a vida complexa para você.

Responder3

Passei uma hora perseguindo esse problema depois de mover alguns dos arquivos de serviço. O link simbólico /lib/systemd/systemapontava para o arquivo correto, mas o link simbólico /etc/systemd/systemnão estava (seu alvo não existia mais). Removi esse link simbólico ofensivo (quebrado), substituí-o pelo correto e funcionou.

Responder4

Teve um problema semelhante, usamos podman sem root no centos7.

O contêiner não foi iniciado após a reinicialização, os serviços não foram encontrados. Mas antes da reinicialização, os serviços estavam habilitados e presentes em /etc/systemd/system. Os serviços foram criados via syslink ln -s de /home/user para /etc/systemd

Quando você executa após a reinicialização, Systemctl status nameOfService.serviceele retorna "Unit servicename.service não pôde ser encontrado."

Quando você executa systemctl daemon-reloado serviço está presente novamente.

Uma solução possível é criar um syslink ln -s de /root/ para /etc/systemd/system - após a reinicialização, seu serviço ainda existirá.

Melhor solução

  • Crie seu próprio serviço que executa o daemon-reload e inicia seu serviço

Crie o script startServiceOnBoot.sh com daemon-reload e inicie seu serviço

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

Tornar o script sh executávelchmod +x startServiecOnBoot.sh

Crie seu serviço /etc/systemd/system/serviceStarter.service

[Unit]
Description=Daemon Reloader
...

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

[Install]
WantedBy=multi-user.target

Habilite o serviço na inicialização, systemctl enable serviceStarter.servicevocê também pode verificar se iniciar seu novo serviço serviceStarter.service realmente inicia nameOfService.service também.

Tentei After= e .timer com serviços no systemd, mas não obtive sucesso. Para depurar a culpa de $ systemd-analyze

informação relacionada