Hilfe bei Erstellung einer systemd Service Unit mit Verwendung von ExecStartPre/ExecStartPost

  • Hallo,

    möchte eine Systemd Service Unit erstellen, welche von einem systemd Timer angesprochen wird zur regelmäßigen Datenbanksicherung.

    Jetzt bin ich auf die Idee gekommen, dass ich über die Service Unit für das Backup ja das entsprechende Programm welches die Datenbank verwendet stoppen und nach Beendigung des Backups wieder starten könnte.

    In etwa so (was aber nicht funktioniert):

    Fehlerausgabe:

    Das ist also wohl nicht so gedacht, dass man das systemctl Befehle darüber absetzen kann.

    Mir kam halt der Gedanke, da man ja auch in Requisite (u.ä) direkten Einfluss auf Units nehmen kann.

    Natürlich könnte ich das starten und stoppen im Backupskript selbst vornehmen...aber gibts für mein vorhaben auch eine "systemd Lösung?"

  • Hilfe bei Erstellung einer systemd Service Unit mit Verwendung von ExecStartPre/ExecStartPost? Schau mal ob du hier fündig wirst!

  • ... und nach Beendigung des Backups wieder starten könnte.

    In etwa so (was aber nicht funktioniert):

    Code
    ExecStart=/bin/bash /home/pi/db_backup/db_backup.sh
    ExecStartPost=systemctl start picoffee.service

    Ist das so, dass:

    Code
    ExecStartPost=

    warten würde bis

    Code
    /bin/bash /home/pi/db_backup/db_backup.sh

    vollständig ausgeführt ist? ich denke mit "ExecStartPre" und "ExecStartPost" wird nur die Reihenfolge der Ausführung bestimmt.

    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-p6 (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

  • ExecStartPre=systemctl stop picoffee.service
    ExecStart=/bin/bash /home/pi/db_backup/db_backup.sh
    ExecStartPost=systemctl start picoffee.service

    Das kann nicht funktionieren.... im Idealfall würde backup.sh gestartet, es forkt sich weg (damit der Prozess den systemd-timeout (90 sec.)) überlebt. Das bedeutet, stop picoffee und start picoffee erfolgen somit eigentlich direkt aufeinander, obwohl im Hintergrund noch backup.sh werkelt. Soweit wegen start/stop picoffee die erste Fehlersituation.

    Die zweite Fehlersituation, die hier noch wahrscheinlicher ist, wird picoffee gestopt, backup.sh werkelt im Vordergrund (ohne fork) solange, bis es von systemd nach timeout gekillt wird (also backup=kaputt), und dann wird picoffee wieder gestartet.

    Eine Systemd-Service-Unit kann NUR Kurzläufer starten (simple oder besser oneshot), oder Langläufer, die trotzdem sofort zurückkkehren (weil sie sich geforkt haben).... egal wie, ExecStart hat nur 90 Sek. Zeit um erfolgreich zu sein... danach greift erwünscht und planmäßig systemd ein.

    Ich würde auch von einer timerunit keine weitere unit starten, sondern einfach direkt den Job, der alles von Anfang bis Ende durchführt.... aber eben unter der Prämisse, dass das mit ExecStart gestartete Programm sofort mit exit 0 zurückkommt. Der Backup-Job kann ja als Fork weiterlaufen.

  • vollständig ausgeführt ist?

    Ja, das ist so, weil ja ExecStartPre und ExecStart Dinge erfolgreich zuende gebracht haben müssen, damit ExecStartPost eben vollständige "Fakten" vorfindet. Das rast also nicht einfach durch, unabhängig davon, ob ein Teilschritt erfolgreich war. Man kann ja auch mehrere abhängige Pre-Commands ausführen, die alle nacheinander wie in einem Script abgeabeitet werden, einer NACH dem anderen..... wenn der Vorgänger erfolgreich (exit 0) war. Ein Teilschritt mit exit 1 beendet, unterbricht den Verlauf und die Unit geht in Failstate.

  • Ja, das ist so, weil ja ExecStartPre und ExecStart Dinge erfolgreich zuende gebracht haben müssen, ...

    Aber mit "vollständig ausgeführt" meinte ich ja nicht "ExecStartPre und ExecStart", sondern "/home/pi/db_backup/db_backup.sh" (siehe oben).

    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-p6 (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

  • (damit der Prozess den systemd-timeout (90 sec.)) überlebt

    ||Stimmt da war ja was, erst kürzlich im anderen Thread - und ich hab auch noch selbst dazu Tests gemacht.

    Ja?

    also, ich wollte es ja schon lange mal loswerden, aber den Hinweis das kernel und subystem fehlen gab ich dir in Antwort #4. ;)

    Das einzige was ich bisher auch nicht wusste, jetzt schon dank gugus und @ThomasL ist, dass die Skripte nach einer gewissen Zeit abgeschossen werden.

    Bei mir beträgt diese Zeit übrigends 180 Sekunden:

    Code: /etc/udev/rules.d/90-usb_runtime_test.rules
    ACTION=="add", SUBSYSTEMS=="usb", KERNEL=="sd*[0-9]", RUN+="/usr/bin/python3 /home/pi/runtime_udev_test.py"
    Code: /home/pi/runtime_udev_test.log
    ...
    Zeit: 20:51:42, Dauer: 179.500815
    Zeit: 20:51:43, Dauer: 180.50319

    Bei mir waren es nur komischerweise immer 180 Sekunden - aber ja du hast recht das diese Konstellation dann natürlich für das Backup nicht zu gebrauchen ist.


    Der Backup-Job kann ja als Fork weiterlaufen.

    Das erreiche ich dann Schätzungsweise mit dem Type=forking ?!

    Ich würde auch von einer timerunit keine weitere unit starten, sondern einfach direkt den Job

    :conf:-bisher ging ich immer davon aus, dass ich mit einer timerunit nur service units und keine Skripte starten kann.

    rpi444 ich hoffe doch stark, dass das so funktioniert, sonst wären die Begrifflichkeiten und Funktionen ziemlich umsonst. Aber dazu hat @ThomasL mittlerweile schon was dazu gesagt, sonst hätte ich noch eine Testreihe starten müssen.

  • rpi444 ich hoffe doch stark, dass das so funktioniert, sonst wären die Begrifflichkeiten und Funktionen ziemlich umsonst.

    Was soll den funktionieren oder nicht funktionieren? Du hast wohl auch nicht verstanden was ich geschrieben bzw. gemeint habe?

    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-p6 (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

  • Du hast wohl auch nicht verstanden was ich geschrieben bzw. gemeint habe?

    Was ich verstanden habe:

    1. ExecStartPre=systemctl stop picoffee.service
      Befehl wird gestartet, sobald die Abarbeitung erfolgreich war wird mit Schritt 2 begonnen
    2. ExecStart=/bin/bash /home/pi/db_backup/db_backup.sh
      Befehl wird gestartet nachdem Schritt 1 erfolgreich beendet wurde. Nach erfolgreicher Beendigung wird Schritt 3 gestartet
    3. ExecStartPost=systemctl start picoffee.service
      Befehl wird gestartet nachdem Schritt 2 erfolgreich beendet wurde. Nach erfolgreicher Beendigung wurde die Service Unit vollständig erfolgreich ausgeführt

    So habe ich deine Frage verstanden und so verstehe ich auch zugleich die Funktion der einzelnen Optionen.

    EDIT:

    Was soll den funktionieren oder nicht funktionieren?

    Die Abarbeitung der einzelnen Befehle in der oben dargestellten Reihenfolge - sry lange Leitung

  • Aber mit "vollständig ausgeführt" meinte ich ja nicht "ExecStartPre und ExecStart", sondern "/home/pi/db_backup/db_backup.sh" (siehe oben).

    Ich glaube, das hatte ich auch so verstanden. ExecStartPost wird erst ausgeführt, wenn backup.sh erfolgreich beendet ist, oder eben auch nicht, wenn backup.sh mit exit 1 zurückkehrt und auch nicht, wenns von systemd wegen timeout gekillt wurde.


    Das erreiche ich dann Schätzungsweise mit dem Type=forking ?!

    Nein, nicht alleiine, der Type-Parameter ist nur für systemd das flag, wie systemd die Unit behandeln soll. Das forken muss dann schon der Prozess selber übernehmen.

    bisher ging ich immer davon aus, dass ich mit einer timerunit nur service units und keine Skripte starten kann.

    Ja, das ist -soweit ich mich erinneren kann- irgendwie richtig und auch irgendwie falsch. Zur Timer-Unit gehört immer mit dem gleichen Namen eine Service-Unit, die schliesslich dann den Job startet. Ich sehe das immer als eine Einheit... deswegen hast Du auch nicht ganz Unrecht.. Aber eine Timer-Unit kann, soweit ich weiss, nicht eine beliebige Service-Unit starten, sondern sie startet automatisch eine mit dem gleichen Namen... die damit also die eigentlichen Job-Daten der Timer-Unit enthält.

  • Was ich verstanden habe:

    1. ExecStartPre=systemctl stop picoffee.service
      Befehl wird gestartet, sobald die Abarbeitung erfolgreich war wird mit Schritt 2 begonnen
    2. ExecStart=/bin/bash /home/pi/db_backup/db_backup.sh
      Befehl wird gestartet nachdem Schritt 1 erfolgreich beendet wurde. Nach erfolgreicher Beendigung wird Schritt 3 gestartet
    3. ExecStartPost=systemctl start picoffee.service
      Befehl wird gestartet nachdem Schritt 2 erfolgreich beendet wurde. Nach erfolgreicher Beendigung wurde die Service Unit vollständig erfolgreich ausgeführt

    ... so verstehe ich auch zugleich die Funktion der einzelnen Optionen.

    Das habe ich aber so nicht geschrieben.

    Ich habe gefragt ob "ExecStartPost=systemctl start picoffee.service" _wartet_ bis das Script "/bin/bash /home/pi/db_backup/db_backup.sh" _vollständig_ ausgeführt ist und nicht lediglich nur gestartet worden ist (mit "ExecStart=").

    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-p6 (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

  • Die Abarbeitung der einzelnen Befehle in der oben dargestellten Reihenfolge

    Das passiert auch genau so.... nur eben unter der Beschränkung eines Timeouts. Probiers doch einfach mit mit einem /bin/sleep 240 statt backup.sh und Type simpel. Dann weisst Du ganz genau was passiert. Mit type simple ist das noch ne Besonderheit, da ist systemd großzügiger..... ich hatte da mal was am Laufen, was eigentlich auch kein echter fork war..... ich würds einfach mal mit sleep ausreizen.

  • ExecStartPost wird erst ausgeführt, wenn backup.sh erfolgreich beendet ist, oder eben auch nicht, wenn backup.sh mit exit 1 zurückkehrt und auch nicht, wenns von systemd wegen timeout gekillt wurde.

    OK, danke. Das ist die Antwort auf meine Frage.

    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-p6 (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

  • Bzgl dem Timeout nochmals eine Frage.

    Zählt denn schon als "wegforken" wenn man ansich direkt python mit der Unit anspricht, und python führt dann das Skript aus?

    Denn ansonsten wär es mir nicht erklärbar, wie denn z.B mein Wetterbot oder picoffee dauerhaft in einer Endlosschleife laufen kann, obwohl es von einer Service Unit aus gestartet worden íst:

    Code
    pi@wetterstation:~ $ systemctl status wetterbot.service
    ● wetterbot.service - ServiceUnit zum starten des Wetterbots
       Loaded: loaded (/etc/systemd/system/wetterbot.service; enabled; vendor preset
       Active: active (running) since Thu 2019-01-24 18:24:13 CET; 3 weeks 4 days ag
     Main PID: 18380 (python3)
       CGroup: /system.slice/wetterbot.service
               └─18380 /usr/bin/python3 /home/pi/Wetterbot/wetterbot.py
    Code
    pi@wetterstation:~ $ cat /etc/systemd/system/wetterbot.service
    [Unit]
    Description=ServiceUnit zum starten des Wetterbots
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/python3 /home/pi/Wetterbot/wetterbot.py
    
    [Install]
    WantedBy=multi-user.target
  • nee, forken (i.ü.S.) würde bedeuten, dass python Dein Programm forkt und sich sofort selber wieder beendet.... also eine Situation, die wegen Interpreter hier gar nicht möglich ist.

  • @ThomasL die Begründung verstehe ich nicht. Warum kann denn angeblich ein interpretiertes Programm keinen Gebrauch von fork und exec* machen? In Python im Modul os.

    Vor dem Hintergrund wäre meine Begründung auch völliger Unsinn. Nur hat deine Darstellung leider gar nix mit hofeis Frage gemeinsam und insofern passt meine Begründung auch nicht zu deinem Beispiel.

    Seine Frage bezieht sich darauf, dass Python als "primäre" Instanz das/sein Programm als fork startet, was es aber nicht ist/tut. Aus Sicht von Python ist sein Programm nichts anderes als ein Writer-Dokument für LO-Writer oder ein Sheet für LO-Calc. Er muss also aus dem von der Unit gestarteten Python (plus Script) ein geforktes Python (wieder plus Script) machen. Das entspricht dann deiner Beschreibung.

  • Bzgl dem Timeout nochmals eine Frage.

    Denn ansonsten wär es mir nicht erklärbar, wie denn z.B mein Wetterbot oder picoffee dauerhaft in einer Endlosschleife laufen kann, obwohl es von einer Service Unit aus gestartet worden íst:

    Code
    pi@wetterstation:~ $ systemctl status wetterbot.service
    ● wetterbot.service - ServiceUnit zum starten des Wetterbots
       Loaded: loaded (/etc/systemd/system/wetterbot.service; enabled; vendor preset
       Active: active (running) since Thu 2019-01-24 18:24:13 CET; 3 weeks 4 days ag
     Main PID: 18380 (python3)
       CGroup: /system.slice/wetterbot.service
               └─18380 /usr/bin/python3 /home/pi/Wetterbot/wetterbot.py

    Ich denke hier in sollte man auch den Zustand "active (running)" der Service-unit sehen/betrachten. Denn dieses "active (running)" bezieht sich nicht auf den python3-Process mit der PID 18380.

    Als Vergleich hier z. B. eine service-unit mit dem Zustand "active (exited)":

    Code
    :~ $ systemctl status wpa_supplicant-nl80211@wlan0.service
    ● wpa_supplicant-nl80211@wlan0.service - WPA supplicant daemon (interface- and nl80211 driver-specific version)
       Loaded: loaded (/lib/systemd/system/wpa_supplicant-nl80211@wlan0.service; enabled)
       Active: active (exited) since Mon 2019-02-18 20:05:22 CET; 14h ago
     Main PID: 360 (code=exited, status=0/SUCCESS)

    D. h. der wpa_supplicant ist aktiv, die Service-unit ist auch aktiv aber sie wird nicht mehr "ausgeführt". D. h. diese Service-Unit kann den wpa_supplicant auch nicht mehr permanent "überwachen", mit z. B. "Restart=on-failure" oder Gleichwertiges.

    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-p6 (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

  • Habe gerade 3 Versuchsreihen durchgeführt, mit der Erkenntnis, dass die 90 Sekunden Beschränkung (Timeout) nur dann greift, wenn ExecStartPre= oder ExecStartPost= zum Einsatz kommt.

    Wird nur ExecStart= verwendet, läuft das Skript ohne Abbruch, wie schon vermutet, sonst würde ja auch meine anderen Projekte wie der Wetterbot oder picoffee oder das auslesen vom Stromzähler nicht funktionieren, denn all diese Projekte starte ich mit einer Service Unit welche im Programm dann in einer while True Schleife laufen.

    Die 3 Python Dateien sehen wie folgt aus, im Grunde sind alle identisch, nur bei runtime_test.py ist die Laufzeit der Schleife verlängert:

    Alle aktiven Skripte teilen sich eine Logdatei. Zur Unterscheidung beinhaltet jede Eintragung zuerst den Namen der Pythondatei, welche den Eintrag schreibt, die aktuelle Uhrzeit und die Laufdauer des Skriptes.


    Variante 1:

    Service Unit besteht nur aus ExecStart=

    Code
    [Unit]
    Description=Runtime Test Systemd
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/python3 /home/pi/runtime_test/runtime_test.py
    
    [Install]
    WantedBy=multi-user.target

    Ausgabe der Logdatei:

    Wie man sieht wird die while Schleife Planmäßig nach 6 Minuten verlassen, es findet somit kein Abbruch nach 90 Sekunden statt.

    Variante 2:

    Service Unit besteht aus ExecStartPre=, ExecStart=, ExecStartPost=

    Ausgabe der Logdatei:

    Code
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:55:18, Dauer: 10.00914
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:55:28, Dauer: 20.021624
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:55:38, Dauer: 30.035059
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:55:48, Dauer: 40.045035
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:55:58, Dauer: 50.052944
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:56:08, Dauer: 60.061628
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:56:18, Dauer: 70.075023
    File: /home/pi/runtime_test/pre_runtime_test.py: Zeit: 15:56:28, Dauer: 80.085027

    Hierbei kam es zum Abbruch nach 90 Sekunden. Wie man sieht sind auch nur Einträge der pre_runtime_test.py enthalten.

    Variante 3:

    Service Unit besteht aus ExecStart=, ExecStartPost=

    Ausgabe der Logdatei:

    Aufgrund der selben Uhrzeit bei gleicher Dauer müssen runtime_test.py und post_runtime.py zeitgleich (nicht auf die millisekunde genau, aber es wurde auf keinen Fall gewartet bis runtime_test.py erfolgreich durchgelaufen ist) gestartet worden sein.

    Hierbei kam es wieder zu einem Abbruch nach 90 Sekunden.


    Auf alle Fälle weiß ich jetzt auch, das ich über die Service Unit keine anderen Units zuvor beenden und anschließend wieder starten lassen sollte - was eigentlich schade ist - aber dann muss das, dass Backup Skript übernehmen.

  • ...mit der Erkenntnis, dass die 90 Sekunden Beschränkung (Timeout) nur dann greift, wenn ExecStartPre= oder ExecStartPost= zum Einsatz kommt.

    Das ist nicht ganz richtig interpretiert, sondern imho nur eine symptomatische Beobachtung. Richtig ist es, den Unterschied zwischen Type "forking" und "simple" zu erkennen.... und zu verstehen, inwievern für beide trotzdem gleichermaßen die Timeout-Grenze gilt.

    Für beide Unit-Typen gilt grundsätzlich die Regel, beide Units müssen innerhalb des Timeouts fertig werden, sonst werden sie gekillt. Im Unterschied zum Type "simple" wird beim Type "forking" jedoch erwartet, dass der gestartete Haupt-Prozess selber umgehend zurückkehrt, nachdem er sich "geforkt" hat. Das bedeutet, systemd wartet bis zum Timeout darauf, dass der Prozess "erfolgreich" zurückkkehrt. Beim Type "simple" wird nicht gewartet, systemd startet und überlässt den Job dann sich selbst und kehrt unabhängig vom Job-Status sofort zurück.... der Prozess läuft weiter, ohne sich geforkt zu haben. Das ist vermutlich alten Programmen (sysvinit) geschuldet, die trotzdem über den Systemstart laufen müssen, auch wenn sie sich nicht forken können. Darüber hinaus ist damit auch der Status der Unit fragwürdig, denn er enthält vermutlich keine Infos, wenn der Job aufgrund eines fehlenden Sachverhalts nicht arbeiten kann und sich mit failstate beendet. Ich weiss auch gerade gar nicht, was mit stdout's passiert und ob die im Unit-Status sichtbar bleiben, was sie normalerweise bei geforkten und remain-Units sind. Tja, es geht also irgendwie, ich empfinde das jedoch als einigermaßen unsauber.... ist imho halt Quick&Dirty-Technik.

    Die künstlich eingestellte Wartezeit bei Pre- oder Post-Statements verhindert einfach nur, dass die Unit selber innerhalb des Timeout zurückkehrt., also wird sie platt gemacht, völlig unerheblich, ob simple oder forking.

  • systemd startet und überlässt den Job dann sich selbst und kehrt unabhängig vom Job-Status sofort zurück.... der Prozess läuft weiter, ohne sich geforkt zu haben. Das ist vermutlich alten Programmen (sysvinit) geschuldet, die trotzdem über den Systemstart laufen müssen, auch wenn sie sich nicht forken können.

    Darüber hinaus ist damit auch der Status der Unit fragwürdig, denn er enthält vermutlich keine Infos, wenn der Job aufgrund eines fehlenden Sachverhalts nicht arbeiten kann und sich mit failstate beendet

    Hoffentlich habe ich dich jetzt richtig verstanden, sonst wär der Test umsonst gewesen.

    Ja auch laufende Prozesse (in dem Fall mein Skript) lässt sich wieder mit systemctl stop runtime_test.service beenden.

    Ebenso lässt sich mittels systemctl status runtime_test.service der aktuell befindliche Status abfragen.

    Mein Testskript hat einen absichtlichen Fehler eingebaut bekommen, sodass es nach 3 Minuten abstürzt, auch dies ist ersichtlich mit systemctl status runtime_test.service. Die Restart= Option lässt sich auch dafür nutzen, ein abgestürztes Skript wieder zu starten (das war damals der Grund warum ich eine Service Unit für meine Skripte verwendete)

    Diesesmal die Ausgabe als Bild, da ist die Farbgebung besser zu erkennen. Sogar der Fehlergrund wird mitprotokulliert.

    Bei inaktiv(dead) hatte ich zuvor ein systemctl stop abgesetzt, anschließend wird auch nichts mehr in die Log Datei eingetragen

    alten Programmen (sysvinit) geschuldet, die trotzdem über den Systemstart laufen müssen,

    Bedeutet dann aber auch, dass eine Service Unit crontab nicht direkt ersetzen kann, da crontab ja nicht für den Systemstart zuständig ist.

    Meine ursprüngliche Frage hat sich aber dennoch erübrigt, deswegen wird der Thread ansich mal auf erledigt gesetzt

Jetzt mitmachen!

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