Stimmt. Ich war einfach implizit davon ausgegangen, dass dein Vorschlag vollständig ist und hab den daher so übernommen.
Beiträge von 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...
-
Gerade nochmal geckeckt: ist jetzt fast 1:1 Berichtigungs Lösung
Ich hatte das auch schonmal so, aber ohne die Install-Sektion, ohne die aber nix geht... -
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.
Code
Alles anzeigen[Unit] Description=Backup all relevant data DefaultDependencies=no Before=shutdown.target halt.target Conflicts=reboot.target [Service] Type=oneshot ExecStart=/home/backup-data.sh [Install] WantedBy=poweroff.target halt.targetDas 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.
-
Bei mir startet der Dienst dann einmal sofort nach diesem Befehl. Beim Reboot/ Shutdown dann nicht mehr.
Damit startet der Dienst beim Hochfahren, aber nicht beim Reboot/ Shutdown.
-
Mittels systemctl enable data-backup.service? Ja, habe ich. Siehe Anhang.
Nach dem Reboot ist die Datei noch immer nicht vorhanden. Der systemctl status gibt 3 Einträge zurück, weil ich vorher schonmal eine Runde mit systemctl start/ systemctl stop gedreht habe.
-
@Berichtigung
Vielen Dank für den Service. Leider scheint es auch damit nicht zu funktionieren. Jedenfalls wird keine Datei erstellt - weder beim Reboot noch beim Shutdown. Die Übergabeparameter habe ich jetzt weggelassen.backup.service:
Code[Unit] Description=Backup all relevant data DefaultDependencies=no Before=shutdown.target halt.target reboot.target [Service] Type=oneshot ExecStart=/home/backup/backup-data.sh
/home/backup/backup-data.sh:
Rufe ich das Skript in der Konsole ohne Parameter auf, wird die Datei mit dem erwarteten Inhalt generiert.EDIT:
Ich teste das aktuell als root, später soll das Skript aber auch für/ unter normalen Nutzern laufen. Nur falls das auch noch ne Rolle spielt. -
@ThomasS
Nein, da ist nur eine immobile Workstation im Einsatz die dauernd am Strom hängt. Es darf also auch länger dauern. Ein Reboot sollte allerdings möglichst schnell durchgeführt werden, daher sollte das Skript nur beim Herunterfahren ausgeführt werden.@Berichtigung
Bei Verwendung von WantedBy=poweroff.target habe ich die Reihenfolge unter After/ Before umkehrt. -
@Berichtigung
Danke für deine Kritik. Wie ich sehe, war meine Beschreibung nicht ganz vollständig.start und stop dienen mir aktuell nur zum Debuggen, damit ich sehe wann das Skript ausgeführt wurde. Mit dem eigentlichen Backup-Skript hat das natürlich nichts zu tun, das ist richtig. Aber genausowenig hat das eigentliche Backup-Skript etwas mit meinem aktuellen Problem zu tun - nämlich das Skript im gewünschten Moment zu starten.
Mit SystemV hatte ich nie zu tun, und auch keine Ahnung davon.
Meine Anforderungen:
- Ausführung beim Herunterfahren, aber nicht beim Reboot
- Sicherung per LAN auf ein NAS, also Netzwerk und NFS-Mounts müssen noch verfügbar sein
- Skript kann/ soll das Zielverzeichnis mounten und unmounten
- Ausführung nachdem mysql beendet wurdeIch hatte systemd bisher so verstanden, dass man die Reihenfolge von Prozessen/ Diensten beim Hochfahren festlegt und diese dann beim Herunterfahren in genau umgekehrter Reihenfolge wieder beendet werden. Daher die Reihenfolge mit dem After und Before, das Skript würde dann ausgeführt wenn mysql beendet wurde, aber das Netzwerk noch aktiv ist.
Ich habe auch mit WantedBy=poweroff.target experimentiert, aber auch das leider ohne Erfolg.
-
Achso, klar. Den 'ShootmasterII' von Meyton. Ich dachte nicht, dass es für die Fragestellung relevant ist.