☰

Die Servicedatei ist vorhanden, wird aber von systemd nicht gefunden.

tag-icon • tag-icon linux systemd
Die Servicedatei ist vorhanden, wird aber von systemd nicht gefunden.

Ich habe eine systemd-Servicedatei erstellt und in platziert /etc/systemd/system/anfragen-3dkonfig-mapper.service. Ich habe ausgeführt systemctl daemon-reloadund systemctl daemon-reexecdas System neu gestartet.

  • systemctl enable anfragen-3dkonfig-mapperführt zu

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

  • systemctl start anfragen-3dkonfig-mapperführt zu

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

  • ls -lh /etc/systemd/system/anfragen-3dkonfig-mapper.serviceAusgänge

    -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.servicehat einen Exitcode von 0 und druckt keine Ausgabe.

  • mountzeigt an

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

  • Es gibt keine anderen Halterungen, die es berühren /usroder /etc…

  • Der Inhalt der Servicedatei ist:

    [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

  • Alle oben genannten Befehle wurden als rootBenutzer ausgeführt.

  • Betriebssystem: CentOS Linux Version 8.0.1905 (Core)
  • Systemd-Version: 239
  • Linux Kernel: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))
  • Ich erinnere mich vage, dass ich vor einigen Monaten ein ähnliches Problem mit einer anderen Servicedatei hatte, das aber nach ein paar Stunden Herumprobieren und ständigem Umbenennen der Servicedatei wie durch Zauberhand zu funktionieren begann.

Mich interessieren zwei Dinge:

  • Wie behebt man ein solches Problem?
  • Was ist falsch?

Antwort1

Wie von @JdeBP angedeutet, sind falsche SELinux-Dateibezeichnungen der Grund für das Verhalten. Das .Zeichen in der Ausgabe von lsgibt an, dass für die Datei ein Sicherheitskontext festgelegt ist. Achten Sie also auf das .in der lsAusgabe!

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

-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

Man sieht, dass die andere Servicedatei das systemd_unit_file_tLabel hat, der defekte Service jedoch nicht. Dies kann mit behoben werden restorecon anfragen-3dkonfig-mapper.service. Danach sehen die Labels wie folgt aus:

-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 verhält sich jetzt wie erwartet.

Antwort2

-rw-r--r--.

SELinux-Einschränkungen machen Ihnen das Leben schwer.

Antwort3

Ich habe gerade eine Stunde damit verbracht, dieses Problem zu beheben, nachdem ich einige der Servicedateien verschoben hatte. Der Symlink in /lib/systemd/systemzeigte auf die richtige Datei, der Symlink in jedoch /etc/systemd/systemnicht (sein Ziel existierte nicht mehr). Ich habe diesen fehlerhaften (defekten) Symlink entfernt, durch den richtigen ersetzt und es funktionierte.

Antwort4

Hatte ein ähnliches Problem, wir verwenden Rootless Podman auf CentOS7.

Container wurden nach Neustart nicht gestartet, die Dienste wurden nicht gefunden. Aber vor Neustart waren die Dienste aktiviert und in /etc/systemd/system vorhanden. Dienste wurden über syslink ln -s von /home/user nach /etc/systemd erstellt.

Wenn Sie es nach dem Neustart ausführen, Systemctl status nameOfService.servicewird „Unit servicename.service konnte nicht gefunden werden“ zurückgegeben.

Beim Ausführen systemctl daemon-reloadist der Dienst wieder vorhanden.

Eine mögliche Lösung besteht darin, einen Syslink ln -s von /root/ nach /etc/systemd/system zu erstellen – nach dem Neustart ist Ihr Dienst weiterhin vorhanden.

Bessere Lösung

  • Erstellen Sie Ihren eigenen Dienst, der Daemon-Reload ausführt und Ihren Dienst startet

Erstellen Sie das Skript startServiceOnBoot.sh mit Daemon-Reload und starten Sie Ihren Dienst

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

Machen Sie das sh-Skript ausführbarchmod +x startServiecOnBoot.sh

Erstellen Sie Ihren Dienst /etc/systemd/system/serviceStarter.service

[Unit]
Description=Daemon Reloader
...

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

[Install]
WantedBy=multi-user.target

Aktivieren Sie den Dienst beim Booten. systemctl enable serviceStarter.serviceSie können auch überprüfen, ob beim Starten Ihres neuen Dienstes serviceStarter.service tatsächlich auch nameOfService.service gestartet wird.

Ich habe After= und .timer mit Diensten in systemd ausprobiert, aber ohne Erfolg. Zum Debuggen $systemd-analyze blame

verwandte Informationen