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.

    Ich hab meine 3 regelmäßigen Aufgaben jetzt ein paar Tage schon via systemd laufen.


    Da der vorhandene Inhalt der Dateien, in die ich meine Protokollausgaben schreibe, beim öffnen nicht gelöscht (truncated) sondern nur überschrieben wird, wollte ich variable Dateinamen verwenden. Das ist aber leider von systemd nicht vorgesehen. Man kann bei StandardOutput etc. keine Shellvariablen im Dateinamen verwenden. Die Fehlermeldung taucht aber erst bei der Ausführung der Service-Unit im Journal auf und die Unit wird nicht ausgeführt.


    Ich suche zur Zeit noch nach einer Möglichkeit, entweder meine Protokolldateien Dateien beim Start der Unit zu leeren bzw. zu löschen. Da experimentiere ich noch.


    Ich hab aber nach mehrmaligem Lesen der Man-page systemd.units meine selbsterstellten Unit-Files nicht mehr in /etc/systemd/system liegen, sondern in /usr/local/lib/systemd/system. Das hat bei mir sogar den Vorteil, dass ich /usr/local auf der 2. Platte in einer separaten Partition liegen habe und diese bei einem Upgrade meines Systems nicht angepackt wird.


    Da meine Scripte, die ich über systemd ausführen lasse, ja in /usr/local/bin liegen, ist jetzt alles was zusammengehört am gleichen Ort (Partition/Filesystem).


    Man kann sich die Pfade, die von systemd im --system Mode bzw im --user Mode durchsucht werden, anzeigen lassen:


    Pfade im --system Mode

    Pfade im --user mode:

    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 301026 haftet ausdrücklich der jeweilige Autor: Igel1954

    Ich hab mittlerweile etwas zu systemd in deutsch gefunden.


    Der Daemon systemd


    Es handelt sich dabei zwar um ein Kapitel aus dem Administrationshandbuch für den SUSE Linux Enterprise Server 12 SP4, aber ich denke, dass es hilfreich für diejenigen ist, die sich etwas ausführlicher mit systed auseinandersetzen wollen.

    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 301030 haftet ausdrücklich der jeweilige Autor: Igel1954

    Kurz am Rande...

    Zitat von Igel1954

    Es handelt sich dabei zwar um ein Kapitel aus dem Administrationshandbuch für den SUSE Linux Enterprise Server 12 SP4

    Mach im Browser einfach aus "12-SP4" ein "15-SP4" und die Doku ist etwas aktueller ;)

    Der Daemon systemd | SLES 15 SP4
    systemd ist für die Initialisierung des Systems verantwortlich und trägt die Prozess-ID 1. systemd wird direkt vom Kernel gestartet und widersteht de…
    documentation.suse.com


    PS:

    Ich feiere gerade deinen Einsatz für "systemd" :thumbup:

    Für den Inhalt des Beitrages 301031 haftet ausdrücklich der jeweilige Autor: sterun

    Zitat von sterun

    PS:

    Ich feiere gerade deinen Einsatz für "systemd" :thumbup:

    Danke, zu viel der Ehre, ich experimentiere manchmal noch, wenn ich Lust hab und das Thema für mich interessant ist.


    systemd ist, mMn, flexibler als cron, da ich im .timer über den OnCalender-Eintrag diverse Eingabemöglichkeiten habe. In der Crontab müsste ich da mehrere Zeilen schreiben.

    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 301036 haftet ausdrücklich der jeweilige Autor: Igel1954

    Mir ist jetzt in den letzten Tag noch etwas negatives zu gestoßen. Nach einem, durch einen Patch erzwungenen, Neustart wurden meine 3 systemd-timer nicht sauber wieder aktiv gesetzt. Vermutlich ist hier systemd etwas zu früh, weil meine systemd-timer und -services ja in /usr/local/lib/systemd/system liegen.


    Ich musste sie manuell wieder aktivieren.


    Jetzt versuche ich durch Tests herauszufinden, weleche Angaben im Bereich [Init] zusätzlich notwendig sind, um das aktivieren der Timer zu verzögern.


    Ich hab bisher nur die folgenden targets iin [Init] angegeben:


    Code
    [Unit]
Wants=network-online.target local-fs.target

    Ich muss jetzt erstmal schauen, welche Targets ich an dieser Stelle noch als Sync-Point angeben muss/kann.

    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 301156 haftet ausdrücklich der jeweilige Autor: Igel1954

    Zitat von Sauerland

    Ich hab jetzt nicht alles nochmal nachgelesen, aber warum benutzt du nicht /etc/systemd/?

    /usr/local/ ist eine eigene Partition auf der Platte auf der auch meine Home-Partition liegt, und da gehen dann die Daten auch nicht verloren, wenn ich mal Linux komplett neu installieren müsste. Und /usr/local/lib/systemd/system ist ja auch im Suchpfad (systemd-analyze --system unit-paths ).


    Beim aktivieren der Timer wird ja auch ein Link nach /etc/systemd/system gesetzt:


    Code
    igel01:~ # systemctl reenable --now BackupFS.timer BorgBackup.timer Update_OS.timer 
Removed /etc/systemd/system/multi-user.target.wants/BackupFS.timer.
Removed /etc/systemd/system/multi-user.target.wants/BorgBackup.timer.
Removed /etc/systemd/system/multi-user.target.wants/Update_OS.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/BackupFS.timer → /usr/local/lib/systemd/system/BackupFS.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/BorgBackup.timer → /usr/local/lib/systemd/system/BorgBackup.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/Update_OS.timer → /usr/local/lib/systemd/system/Update_OS.timer.
igel01:~ #

    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 301159 haftet ausdrücklich der jeweilige Autor: Igel1954

    Zur Zeit experimentiere ich noch mit einigen Einstellungen. Ich habe mal die Parameter Nice=19, IOSchedulingClass=2 und IOSchedulingPriority=4 gesetzt, aber meine Werte haben dadurch wohl die Laufzeit der Sicherung verdoppelt, so dass ich die 3 Parameter wohl wieder lösche und damit wieder auf die Standardwerte zuücksetze.


    Ich hab bei meiner Suche nach Beschreibungen von Beispielen einen Artikel der LinuxUSer aus 07/2018 gefunden:


    Systemd-Units verstehen und selbst schreiben


    Der Artikel beschreibt den Aufbau einer Systemd-Unit für autofs.


    Der Artikel hat mir weiter geholfen, um meine selbst erstellten Systemd-Units zu verbessern. Ich glaube dabei auch den Grund gefunden zu haben, weshalb meine Timer-Units beim Neustart des OS nicht gestartet werden. Ich muss das bisher nach einem Neustart manuell auslösen.


    Wenn ich meine Systemd-Units soweit habe, dass auch der Start der Units nach einem Neustart des OS automatisch erfolgt, stelle ich eine als Beispiel hier ein.

    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 301312 haftet ausdrücklich der jeweilige Autor: Igel1954

    Ich hab in Youtube den Channel tutorialLinux gefunden.


    Hier gibt es eine Playlist mit 5 Videos zum Thema systemd: https://www.youtube.com/playli…QaMKPbuVpGuqUQYRiTwTAmqeI


    tutorialLinux benutzt eine wohl eine Distri namens minibuntu. Hier sind die Pfade für systemd anders als unter openSUSE, ansonsten ist die Playlist ein guter Einstieg in systemd.

    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)

    2 Mal editiert, zuletzt von Igel1954 ()

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

    Mittlerweile hab ich den "Fehler" gefunden, weshalb meine Systemd-Units nach einem Neustart nicht gestartet wurden.


    Obwohl /usr/local/lib/systemd/system in der Suchreihenfolge der Pfade auftritt, verweigert systemd den Start der Timer-Units.

    Die Timer-Units hatte ich schon nach /etc/systemd/system kopiert und trotzdem bekam ich beim Booten eine Fehlermeldung:


    Code
    igel01:~ # journalctl -u BackupFS.timer
-- Reboot --
Sep 12 09:33:06 igel01 systemd[1]: BackupFS.timer: Refusing to start, unit BackupFS.service to trigger not loaded.
Sep 12 09:33:06 igel01 systemd[1]: Failed to start BackupFS --timer.

    Ich hatte bei der Recherche im Netz nach dieser Fehlermeldung einen Eintrag gefunden, dass jemand auch dieses Problem, Timer- und Service-Units in /usr/local/lib/systemd/system abgelegt, hatte. Sein Problem löste sich, nachdem er diese Files nach /etc/systemd/system kopiert hatte.

    Es müssen demnach Timer- und zugehörige Service-Unit zusammen in /etc/systemd/system abgelegt sein.


    Ich habe jetzt auch die Service-Units nach /etc/systemd/system kopiert und jetzt funktioniert es. Habe aber aus Backupgründen die Unit-Files zusätzlich in /usr/local/lib/systemd/system belassen.

    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 301330 haftet ausdrücklich der jeweilige Autor: Igel1954

    Gefällt mir 1