systemd Backup-Service

Hinweis: In dem Thema systemd Backup-Service gibt es 44 Antworten auf 5 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ich weiss, das der Dienst dann im Init3 (mehr ist multi-user.target nicht) startet, das war nur ein Beispiel.


    Lies mal den Link zum Debian Forum.......
    Da geht es auch ums Backup beim shutdown.

    Für den Inhalt des Beitrages 114242 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Danke für den Link. Ich habe jetzt mal den Service aus dem Beitrag [gelöst] Shutdown-Skript für systemd - debianforum.de genommen. 1-zu-1 übernommen funktioniert das erstmal auch nicht. Nach gefühlten 50 Testläufen habe ich jetzt aber eine Variante, die sich so verhält wie ich das gerne hätte. D.h. die ein Skript nur beim Herunterfahren ausführt und nicht beim Reboot und nicht beim Hochfahren.


    Das Ergebnis entspricht bis auf wenige Details der Lösung von Berichtigung.

    Das Conflicts=reboot.target ist nötig um die Ausführung beim Reboot zu verhindern. Mit RemainAfterExit=yes aus meinem ersten Versuch geht gar nichts. Der Service läuft dann zwar angeblich wenn man den Status abfragt, aber das Skript wird nicht ausgeführt.


    Was ich jetzt noch nicht weiß ist wie die Reihenfolge damit konkret aussieht. Das werde ich jetzt noch versuchen herauszufinden.

    3 Mal editiert, zuletzt von myscha ()

    Für den Inhalt des Beitrages 114252 haftet ausdrücklich der jeweilige Autor: myscha

  • Gerade nochmal geckeckt: ist jetzt fast 1:1 Berichtigungs Lösung :smilie_hops_011:
    Ich hatte das auch schonmal so, aber ohne die Install-Sektion, ohne die aber nix geht...

    Für den Inhalt des Beitrages 114255 haftet ausdrücklich der jeweilige Autor: myscha

  • Eine Install Section ist zwingend für einen Service.

    Nach deinem ersten, alles vernichtenden Urteil habe ich mich eben exakt an deinen Vorschlag gehalten... ;)


    Absolute Pfade in allen Skripten, die vom Service aufgerufen werden? OK, da wäre ich jetzt faul gewesen und hätte es nicht getan...

    Für den Inhalt des Beitrages 114278 haftet ausdrücklich der jeweilige Autor: myscha

  • Stimmt. Ich war einfach implizit davon ausgegangen, dass dein Vorschlag vollständig ist und hab den daher so übernommen.

    Für den Inhalt des Beitrages 114319 haftet ausdrücklich der jeweilige Autor: myscha

  • Das gilt generell für alle Scripte, die von systemd verwaltet werden.


    Oder präzise: Für Scripte, die kein "passendes" Environment haben. Da dann keine PATH Variable definiert ist, die Befehle also nicht gefunden werden können.


    Manche Befehle gibt es als ausführbares Binary, also einem "echten" Programm, UND als internes Bashkommando.
    Dein echo hätte funktioniert, weil es eben sowohl extern, wie intern vorhanden ist.
    Man kann sich darauf aber nicht verlassen.
    Der User könnte eine andere Shell haben. Es kann sich die ja frei einstellen.


    Genauso wichtig, wie absolute Pfade, ist die Tatsache, dass diese Scripte kein Terminal haben.
    Deshalb sind alle Ein- und Ausgaben jedes Kommandos umzulenken.
    Würden die Scripte auf STDOUT schreiben wollen, würden sie mit Fehler abgebrochen(, falls man keine entsprechende Einstellung vorgenommen hat).

  • Deshalb sind alle Ein- und Ausgaben jedes Kommandos umzulenken.Würden die Scripte auf STDOUT schreiben wollen, würden sie mit Fehler abgebrochen(, falls man keine entsprechende Einstellung vorgenommen hat).

    Das habe ich nicht verstanden. Ich habe diverse echos und tees für die Ausgabe auf der Console und in ein Logfile. Für Status im KDE kommen noch kdialogs dazu. Alles ohne Berücksichtigung der genannten Punkte.


    Dann habe ich noch eine andere Frage: wie kann ich die Reihenfolge wann der Service gestartet wird beeinflussen?
    Auf die o.g. Art wird der Service ausgeführt nachdem das Netzwerk bereits deaktiviert wurde und sogar die Laufwerke schon un-ge-mountet. Die Daten werden zuerst auf einen USB-Stick gesichert, der extra dafür gemountet wird. Das klappt noch, aber die anschließende Sicherung auf's NAS (via NFS2) schlägt natürlich fehl.

    Für den Inhalt des Beitrages 115271 haftet ausdrücklich der jeweilige Autor: myscha