Regelmäßige Aufgaben statt mit cron mit Systemd durchführen

Hinweis: In dem Thema Regelmäßige Aufgaben statt mit cron mit Systemd durchführen gibt es 21 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Inspiriert durch das Thema von JeyF123 über Probleme mit Cron und den Hinweisen von Sauerland zu systemd-timer als Cron-Alternative, habe ich mich mal an der Überführung einer meiner Cron-Aufgaben nach Systemd versucht.


    Die Aufgabenstellung in meiner /etc/crontab für das EInspielen von Patches und Updates:


    Code
      GNU nano 4.9.2                                                                      /etc/crontab                                                                      
     1 SHELL=/bin/bash
     2 PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
     3 MAILTO=root
     4 #
     8 #
     9 # Mo, MI, Fri openSUSE-Updates einspielen
    10 #
    11 0      0   *   *   1,3,5  root    bash -lc 'Update_OS.rex '
    12 #

    An drei Tagen (Montag, Mittwoch, Freitag) lasse ich durch cron ein Script laufen, das per zypper alle für mich notwendigen Patches und Updates auf meinem Desktop installiert.

    An Hand der Zypper-Returncodes ermittelt das Script auch, ob ein Reboot des Systems erforderlich ist und setzt als letzte Anweisung shutdown -r +30 "Rechner wird in 30 Minuten durchgestartet" ab. Für mich wichtige Informationen schreibt das Script per logger auch in das Journal.



    Um diese Aufgabe per systemd zu lösen, hab ich mich an dem Beispiel von Michael Kofler (https://kofler.info/systemd-timer-als-cron-alternative/) orientiert und in /etc/systemd/system die Dateien Update_OS.timer und Update_OS.service angelegt.


    Da ja im Gegensatz zur Ausführung der Aufgabe mit Cron von Systemd keine E-Mail kommt, lasse ich alle Ausgaben in eine Log-Datei schreiben.


    Mit systemctl enable --now Update_OS.timer wird der Timer aktiviert. Durch die Option --now spart man sich die zusätzliche Start-Anweisung.

    Beim Start meldet Systemd auch Syntax-Fehler. Ich hab dann mehrfach den Timer wieder disablen müssen, um die Timer- bzw. Service-Datei zu korrigieren. Bis beide Dateien anstandslos von Systemd anerkannt wurden, hab ich reichlich Gebrauch von den entsprechenden Man-Pages per Browser gemacht.


    Bei Änderungen am aktiven Timer bzw. Service muß dieser per systemctl reenable --now <timername>.timer oder per systemctl daemon-reload aktualisieren.


    Ich hab für die Umstellung von Cron nach Systemd ca. 7-8 Stunden mit Unterbrechungen (genau weiß ich es nicht) benötigt.


    Die Umstellung der restlichen Cron-Aufgaben (2 Sicherungsaufgaben mit fsarchiver bzw. BorgBackup) werden als nächstes in Angriff genommen.


    Ob die beiden Dateien vom Inhalt her optimal aufgebaut sind, müssen Systemd-Kundige beurteilen, für meine Zwecke reicht das.

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 300908 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Igel1954

    Hat den Titel des Themas von „regelmäßige Aufgaben voncron nach systemd überführen“ zu „Regelmäßige Aufgaben von Cron nach Systemd überführen“ geändert.
  • Vielen Dank dafür.

    Komischerweise habe ich gar keine Benachrichtigung erhalten, obwohl du mich getagged hast.

    Für den Inhalt des Beitrages 300909 haftet ausdrücklich der jeweilige Autor: JeyF123

  • Komischerweise habe ich gar keine Benachrichtigung erhalten, obwohl du mich getagged hast.

    Das kannst du einstellen. Oben auf den Menüpunkt Benachrichtigungen und dann auf das Zahnrad klicken. Dann kannst du einstellen, welche Benachrichtigungen du bekommen willst.

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 300913 haftet ausdrücklich der jeweilige Autor: Igel1954

  • danke. Wobei das total interessant ist. Du hast auch einen Eintrag für Mo, Mi, Freitag zum updaten. Bei mir auch^^. 16:00. Wobei das mit dem automatischen Neustart habe ich nicht so drinnen, sondern via grep, dass es zumindest in einer Datei steht und ich damit Bescheid weiß. Mir fehlt da wohl noch ziemlich viel Wissen.

    Für den Inhalt des Beitrages 300928 haftet ausdrücklich der jeweilige Autor: JeyF123

  • Ich steuere das über die Zypper-Exitcodes.
    Hier mal der Ablauf meines Scriptes:


    1. zypper --gpg-auto-import-keys --non-interactive ref 
      geht hier etwas schief, schläft das Script für 1800 Sekunden. Nach dem 5. vergeblichen Refreshes wird das Script abgebrochen
    2. zypper -vvv pchk --with-optional
      gibt es Patches bekomme ich von Zypper den Exitcode 100 oder 101 gemeldet.
    3. Bei Exitcode 100 oder 101 zypper -vvv patch -y -l --with-optional --with-interactive
      Bei Exitcode 103 wurde zypper upgedatet und der Patch-Befehl wird nochmal abgesetzt.
      Hier bekomme ich entweder einen Exitcode = 0 dann ist alles ok, bei Exitcode 102 setzte ich einen Schalter, dass ein Reboot erforderlich ist.
      Man könnte dem Patch-Befehl noch --with-updates mitgeben, dann würden die Updates aus den anderen Repos direkt mit verarbeitet. Ich hab es für mich aber absichtlich getrennt, damit ich in dem Log eine getrennte Übersicht habe, welche Patches und welche Updates installiert wurden. Ist in meinen Augen übersichtlicher.
    4. Da Patches nur aus den OSS bzw. NON-OSS -Repos kommen, ich aber auch Packages aus dem Packman- Printing-, und Mozilla-Repo habe macht mein Script jetzt noch
      zypper -vvv up -y -l --details --with-interactive, damit ich hier die geänderten Packages bekomme.
    5. Bevor jetzt mein Script zur Endeverarbeitung kommt, setzte ich sicherheitshalber nach ein zypper needs-rebooting ab. Ist ein Reboot erforderlich, bekomme ich hier auch wieder den Exitcode 102 und kann den Reboot-Schalter auf True setzen.
    6. Da jetzt das Script in der Endeverarbeitung ist, wird hier der Reboot-Schalter abgefragt.
      Ist er gesetzt, dann erfolgt der Shutdown -r Befehl. Ich lasse den Shutdown 30 Minuten verzögern, damit mein Script ordnungsgemäß beendet wird. Die Verzögerungszeit ist von mir willkürlich gewählt. Man kann Shutdown auch auf eine bestimmte Uhrzeit setzen oder der verzögerungszeit verkürzen oder verlängern.

    Ich hab mir die Zypper-Exitcodes aus der Zypper-Doku in ein extra Textfile kopiert. Ich hänge es mal an meine Antwort mit an.


    Zypper_Returncodes.txt

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    4 Mal editiert, zuletzt von Igel1954 () aus folgendem Grund: Text ergänzt

    Für den Inhalt des Beitrages 300933 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Für alle, die sich auch für systemd anstelle von cron für die regelmäßige Ausführung bestimmter Aufgaben interessieren, kommt hier noch ein wichtiger Hinweis.


    Unter openSuSE LEAP 15.3 werkelt systemd 246. Die Man-Pages zu systemd auf Freedesktop.org (z. B. : http://www.freedesktop.org/sof…md/man/systemd.timer.html) beziehen sich schon auf systemd 251. Hier gibt es einige Angaben, die unter systemd 246 zu einer Fehlermeldung führen. Ich bin da nämlich bei den möglichen Angaben für StandardOutput auf eine Fehlermeldung gelaufen:

    /etc/systemd/system/Update_OS.service:13: Failed to parse output specifier, ignoring: truncate:/var/log/Update_OS.log


    Beispiel:

    systemd 246: kennt nur StandardOutput = file:/pfad/datei oder StandardOutput = append:/pfad/datei..

    systemd 251: kennt auch StandardOutput= truncate:/pfad/datei.

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 300965 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Mal ne Frage:

    willst du dies nicht nach howtos verschieben (lassen)?

    Du hast recht - da ist es doch besser aufgehoben. Ich hab Alero 'ne PM geschrieben, damit der Thread verschoben wird. Ich hoffe er kann dabei den Titel etwas anpassen.

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 300967 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Alero

    Hat den Titel des Themas von „Regelmäßige Aufgaben von Cron nach Systemd überführen“ zu „Regelmäßige Aufgaben statt mit cron mit Systemd durchführen“ geändert.
  • Ich habe mittlerweile auch meine beiden Sicherungen nach systemd überführt.


    Die laufen bei z. B. zu folgenden Zeiten:


    Montags, Mittwochs und Freitags erfolgt ein Backup mit BorgBackup gegen 7:00, nachdem mein Update-Script ausgeführt worden ist, es werden dabei 3 Sicherungsarchiver (igel01-system-<datetime>, igel01-home-<datetime> und igel01-server-<datetime> erstellt.


    Am Sonntag um 00:00:00 Uhr mache ich eine Filesystem-Backup mit fsarchiver für die Filesysteme, die /home, /public, /srv und /VM beinhalten. Zusätzlich mache ich um 9:00 dann noch zusätzlich ein komplettes Backup mit BorgBackup (wie Mo,Mi,Fri)


    Für die selbe Aufgabe, die z. B. an unterschiedlichen Tagen und vielleicht sogar dabei auch zu unterschiedlichen Uhrzeiten, ausgeführt werden soll, benötigt man bei Cron mehrere Einträge. Bei systemd reicht ein Timer-File und das dazugehörige Service-File:


    Code: systemd.timer
    [Timer]
    OnCalendar=Mon,Wed,Fri *-*-* 07:00:00
    OnCalendar=Sun *-*-* 09:00:00

    Der OnCalender-Eintrag kann beliebig oft auftreten. Man kann hier für jeden Wochentag, Datum, Uhrzeit unterschiedliche Kombinationen erstellen. Beispiele finden sich in den Man-Pages zu systemd.timer(5).


    Für meine Sicherung per BorgBackup sieht das Timer-File so aus:


    Das dazugehörige Service-File sieht so aus:

    Der Install-Block kann Einsatz eines Timers wohl auch weggelassen werden. Da ich mir hier aber nicht ganz sicher bin, ist dieser Block halt in beiden Files vorhanden.


    Mit systemctl list-timers kann man kontrollieren, ob eine Timer-Aufgabe durchgeführt wurde und wann sie das nächste Mal wieder ausgeführt wird.


    Das sieht dann in etwa so aus:

    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Einmal editiert, zuletzt von Igel1954 () aus folgendem Grund: Text ergänzt

    Für den Inhalt des Beitrages 300968 haftet ausdrücklich der jeweilige Autor: Igel1954

  • Noch eine Besonderheit bei dem Service hab ich vergessen zu erwähnen.

    Man kann in einem Service mehrere ExecStart-Anweisungen einsetzen, die alle sequentiell abgearbeitet werden. Nur hat das einen kleinen Nachteil, wenn man die Ausgaben der einzelnen Programme/Scripte nach  StandardOutput=file:/pfad/datei schreiben lässt. Jede ExecStart-Anweisung überschreibt die vorherige Ausgabe. Will man alle Ausgaben der einelnen ExecStart-Anweisungen erhalten, muss man hier mit StandardOutput=append:/pfad/datei arbeiten und evtl. den erzeugten File später händisch bereinigen.


    Ich hatte bei meinem Sonntags-Service zuerst beide Backups in einem Service abhandeln wollen und dabei dann feststellen müssen, dass mein erzeugtes Log-File nur die Ausgaben der letzten ExecStart-Anweisung enthielt. Ich hab mir dann noch mal in den Man-Pages die OnCalender_Möglichkeiten angesehen und dabei dann auch gesehen, dass diese Angabe mehrfach in einem Timer auftreten darf.


    Wie man Status seiner Timer und Services überprüfen kann, beschreibe ich mit dem folgenden Beispiel.


    Mit systemctl status <name>.timer läßt sich prüfen, ober der Timer aktiv ist und auf die nächste Ausführung wartet. Er zeigt auch an, wie der getriggerte Service heißt.


    systemctl status <name>.service zeigt, ob der Service geladen ist, seit wann er inactive ist und von wem er getriggert wird und ob die letzte Ausführung fehlerfrei war.


    EDV-Dinosaurier im Ruhestand


    ich bin /root, ich darf das 8)


    Dinos are not dead. They are alive and well and living in data centers all around you. They speak in tongues and work strange magics with computers. Beware the Dino! And just in case you're waiting for the final demise of these Dino’s: remember that Dino’s ruled the world for 155-million years! (Unknown Author)

    Für den Inhalt des Beitrages 300969 haftet ausdrücklich der jeweilige Autor: Igel1954