Systemd-Dienst bricht beim booten ab, manuell lässt er sich aber starten

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Zusammen,

    nachdem ich eine meiner Service-Dateien umbenannt habe, bricht der Dienst beim booten des Raspi ab. Wenn ich den Dienst manuell starte (sudo systemctl start ....) klappt es aber, womit ich ausschließe, dass die Dienstedatei fehlerhaft ist. Dienst ist enable und daemon-reload habe ich auch schon gemacht. Welche Berechtigung muss Service-Datei haben? Wo bekomme ich mehr Informationen über den Grund des Abbruches?

    sudo systemctl status _rl_automatik_sommer.service

    \u25cf rl_automatik_sommer.service - rl_sommer

    Loaded: loaded (/etc/systemd/system/rl_automatik_sommer.service; enabled; vendor preset: enabled)

    Active: failed (Result: exit-code) since Sun 2021-09-05 22:24:10 CEST; 1min 18s ago

    Process: 575 ExecStart=/usr/bin/python3 -u rl_automatik_sommer.py (code=exited, status=1/FAILURE)

    Main PID: 575 (code=exited, status=1/FAILURE)


    Vielen Danke

  • Systemd-Dienst bricht beim booten ab, manuell lässt er sich aber starten? Schau mal ob du hier fündig wirst!

  • Hast Du vor dem umbenennen, die "alte" service-unit deaktiviert (disabled)?

    Wie war der Name der service-unit vor dem umbenennen?

    Muss der Name der service-unit, mit einem "_" (Unterstrich) anfangen?

    Poste mal die vollständigen Ausgaben von:

    Code
    systemctl cat _rl_automatik_sommer.service
    systemd-analyze blame

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • bug-reporter Das sich der Dienst von Hand starten lässt, heisst nicht, dass es keine Fehler in der Service-Datei gibt. Wenn Du von Hand startest, ist ja das System komplett gestartet. Wenn der Rechner startet, kann es beispielsweise sein, das irgendein Systemteil den Dein Dienst benötigt, noch nicht gestartet ist. Dann wäre das ein Fehler in der Service-Datei, dass da eine Abhängigkeit nicht angegeben ist.

    Falls Du selbst kein ``sys.exit(1)`` oder ``sys.exit("Fehlertext")`` im Quelltext stehen hast, dann gibt es beim Ausführen eine Ausnahme, denn das Programm endet ja offenbar mit einem Exit-Status 1. Normal wäre 0 wenn alles problemlos gelaufen wäre.

    Falls die Standard- und Fehlerausgabe noch nicht in ein Log umgeleitet werden, würde ich das mal machen und schauen was das Programm da ausgibt, wenn es abbricht.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • Das sich der Dienst von Hand starten lässt, heisst nicht, dass es keine Fehler in der Service-Datei gibt. Wenn Du von Hand startest, ist ja das System komplett gestartet. Wenn der Rechner startet, kann es beispielsweise sein, das irgendein Systemteil den Dein Dienst benötigt, noch nicht gestartet ist. Dann wäre das ein Fehler in der Service-Datei, dass da eine Abhängigkeit nicht angegeben ist.

    Ich verstehe das so, dass er am Inhalt der service-unit ja nichts geändert hat. Er hat nur den Namen der service-unit geändert. Und vor der Namensänderung hat die service-unit ja funktioniert. D. h. es sollte eher nicht am unveränderten Inhalt der service-unit liegen.Evtl. ist ja nur der alte Name noch irgendwo als "Abhängigkeit" eingetragen. Das sollte m. E. nicht der Fall sein, wenn er vor dem Umbenennen, die service-unit mit dem alten Namen, deaktiviert (disabled) hat und danach die service-unit mit dem neuen Namen aktiviert (enabled) hat.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo,

    konnte erst heute bischen weiter testen aber hoffe mit folgenden Tests eure Fragen zu beantworten:

    1.) Das was aufgerufen wird ist eine Python-Programm. Habe den Inhalt jetzt vereinfacht und nur mit print("Hello world") bestückt und trotzdem bricht der Ladeprozess ab. Also am Inhalt des Programmes kann es nicht liegen.

    2.) Habe einen neuen Service aufgebaut mit dem gleichen Inhalt und den gleichen Berechtigungen wie die anderen Service nur mit dem Start eines einfachen Python Programmes welches eine LED blinken lässt, und das hat er geladen. Also müssen auch die Service-Dateien sauber sein.

    Ganz komisch alles. Ich schau mir nochmal alles Buchstabe für Buchstabe an.

  • Servicedatei:

    [Unit]

    Description=k41_rl

    After=network.target

    [Service]

    ExecStart=/usr/bin/python3 -u k41_rl_automatik.py

    WorkingDirectory=/home/pi/prodr3/k41

    StandardOutput=inherit

    StandardError=inherit

    Restart=always

    User=pi

    [Install]

    WantedBy=multi-user.target


    Inhalt k41_rl_automatik.py:

    #!/usr/bin/python3

    print("hello")


    ... wie gesagt, läuft nur nicht mit einem reboot. Manueller Start des Dienstes funktioniert.

  • Hallo,

    in /home/pi/ diese Datei speichern

    Code: programmtest.py
    #!/usr/bin/env python3
    
    def main():
       with open('test.txt', 'w') as file:
           file.write('Hallo')
        
    if __name__ == '__main__':
        main()

    chmod +x /home/pi/programmtest.py

    sudo nano /etc/systemd/system/servicename.service

    Code
    [Unit]
    Description=Do something
    
    [Service]
    ExecStart=/home/pi/programmtest.py
    
    [Install]
    WantedBy=multi-user.target

    sudo systemctl enable servicename.service

    sudo reboot

    Jetzt sollte in /home/pi/ eine Datei test.txt erstellt worden sein.

    Woher weist du, dass dein Test nicht funktioniert? Wo denkst du, siehst du die 'print'-Ausgabe?

    Was sagt 'systemctl status' bze. journalctl ?

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • #!/usr/bin/python3

    print("hello")


    ... wie gesagt, läuft nur nicht * mit einem reboot. Manueller Start des Dienstes funktioniert.

    *) mehr wenn Du nachschaust, weil das Skript dann vermutlich schon durchgelaufen ist und sich beendet hat

    Versuch es mal so wenn es schon klein bleiben soll:

    Python
    #!/usr/bin/python3
    from signal import pause
    
    print("hello")
    pause()

    Wie Dennis89 schon schrieb, kannst Du Dir das print() aber auch schenken.

  • (Man verzeihe mir bitte den Doppelpost!)

    Was mich auch etwas irritiert ist folgendes.

    Das spricht für mismatch von Zeichensätzen. Normalerweise ist das ein Listenpunkt / schwarzer Punt im Unicode. Wie ist dieser Fehler entstanden? War das in der Ausgabe schon so oder liegt das an der Übertragung ins Forum?

  • Das spricht für mismatch von Zeichensätzen. Normalerweise ist das ein Listenpunkt / schwarzer Punt im Unicode

    Der Punkt ist in der Terminaldarstellung von systemctl status ..... ein grüner Punkt. Siehe hier Protokoll eines funktionierenden Dienstes:

    systemctl status r3b_blink

    \u25cf r3b_blink.service - r3b_blink

    Loaded: loaded (/etc/systemd/system/r3b_blink.service; enabled; vendor preset

    Active: active (running) since Wed 2021-09-08 16:52:55 CEST; 14min ago

    Main PID: 482 (python3)

    Tasks: 1 (limit: 2059)

    CGroup: /system.slice/r3b_blink.service

    \u2514\u2500482 /usr/bin/python3 -u on_blink.py

    Sep 08 16:52:55 raspberrypi systemd[1]: Started r3b_blink.


    Jetzt zum Testvorschlag von Dennis 89

    Jetzt sollte in /home/pi/ eine Datei test.txt erstellt worden sein.

    ... eine /home/pi/test.txt hat er NICHT erstellt.

    pi@raspberrypi:~ $ systemctl status servicename.service

    \u25cf servicename.service - Do something

    Loaded: loaded (/etc/systemd/system/servicename.service; enabled; vendor preset: enabled)

    Active: inactive (dead) since Wed 2021-09-08 16:52:56 CEST; 6min ago

    Process: 374 ExecStart=/home/pi/programmtest.py (code=exited, status=0/SUCCESS)

    Main PID: 374 (code=exited, status=0/SUCCESS)

    Sep 08 16:52:54 raspberrypi systemd[1]: Started Do something.

    Sep 08 16:52:56 raspberrypi systemd[1]: servicename.service: Succeeded.


    meine Servicedatei hierzu:

    Code
    [Unit]
    Description=Do something
    
    [Service]
    ExecStart=/home/pi/programmtest.py
    
    [Install]
    WantedBy=multi-user.target

    Servis natürlich enabled

    Programm per copy/paste in Datei programmtest.py übertragen

    chmod +x hatte ich gemacht

  • Diesen Dienst habe ich gestern erstellt und er funktioniert:

    [Unit]

    Description=r3b_blink

    After=network.target

    [Service]

    ExecStart=/usr/bin/python3 -u on_blink.py

    WorkingDirectory=/home/pi/prodr3/jobs

    StandardOutput=inherit

    StandardError=inherit

    Restart=always

    User=pi

    [Install]

    WantedBy=multi-user.target


    Quellcode zu: home/pi/prodr3/jobs/on_blink.py

  • Hallo,

    habe jetzt einen Dienst mit Dauerschleife aufgebaut.

    [Unit]

    Description=Mein service_test

    [Service]

    ExecStart=/home/pi/prodr3/jobs/service_test.py

    [Install]

    WantedBy=multi-user.target


    und er läuft:

    pi@raspberrypi:/etc/systemd/system $ systemctl status service_test

    \u25cf service_test.service - Mein service_test

    Loaded: loaded (/etc/systemd/system/service_test.service; enabled; vendor pre

    Active: active (running) since Wed 2021-09-08 17:53:31 CEST; 8min ago

    Main PID: 413 (service_test.py)

    Tasks: 1 (limit: 2059)

    CGroup: /system.slice/service_test.service

    \u2514\u2500413 /usr/bin/python3 /home/pi/prodr3/jobs/service_test.py


    Jetzt gehe ich nochmals an die ursprünglich nicht laufenden Jobs. Kann es sein, dass das umbenennen der Services ein Fehler war der irgendwie anders wieder gerade gebogen werden muss? In den zugehörigen Python-Programmen wird auf MQTT zugegriffen und es werden bash-Skripte ausgeführt. Das war aber alles gar kein Problem bis zum umbenennen der Services.

  • Und jetzt bitte nochmals Deinen Test aus Beitrag #9 (falls das das umgenannte Skript war) und dazu bitte diesmal auch die Stausmeldung nach dem Neustart!

    Dann sehen wir evtl. ob es tatsächlich nicht funktioniert hat oder einfach schon durch war.

  • Bin am kämpfen und habe jetzt so folgendem Service (vereinfacht wie oben vorgeschlagen):

    [Unit]

    Description=k40_rl

    [Service]

    ExecStart=home/pi/prodr3/k40/k40_rl_automatik.py

    [Install]

    WantedBy=multi-user.target


    ....folgende Meldung bekommen


    \u25cf k40_rl.service - k40_rl

    Loaded: bad-setting (Reason: Unit k40_rl.service has a bad unit file setting.)

    Active: inactive (dead)

    Was sind bad unit file settings?

  • Ja, danke :)

    Habe den Fehler jetzt eingekreist. Wenn das vom Service gestartete Python-Programm einfacher Natur ist (mit Bash-Aufruf) so startet der Dienst fehlerfrei. Sobald das Programm komplizierter wird (ich vermute das es die MQTT-Funktionalität ist) so bricht der Dienst ab. Da das nur nach reboot ist und bei manuellem Start nicht, vermute ich, dass MQTT noch nicht "wachgeküsst" ist. Weitere Funktionalitäten außer Bash-Aufruf und MQTT gibt es im Programm nicht. Es muss also der Mosquitto-Service sein der noch nicht geladen ist.

  • wobei Mosquitto doch vorher geladen wird :denker:

    Anbei die zwei Status zu meinem Service und den von Mosquitto.

    Was meint ihr? Wird jetzt zu komplex für mich!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!