Beiträge von myscha

Klar. Bitteschön

[Unit]
Description=Data backup
After=wicked.service
Before=mysql.service
Conflicts=reboot.target


[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/backup/data-backup.sh


[Install]
WantedBy=multi-user.target

und

#!/bin/bash
echo "$(date +"%Y-%m-%d %T") $@" >> /home/backup/test.log
exit 0

Das ExecStart=/bin/true kann weggelassen werden, sofern Type=oneshot und RemainAfterExit=true gesetzt sind.

Mit Conflicts=reboot.target ändert sich leider nichts. Gilt das vielleicht nur im Zusammenhang mit WantedBy=?

So ganz aufgegeben habe ich noch nicht...

Folgende Variante führt das Skript zuverlässig vor dem Herunterfahren und Neustarten aus.

[Unit]
Description=Data backup
After=wicked.service
Before=mysql.service


[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/backup/data-backup.sh


[Install]
WantedBy=multi-user.target

Gibt es eine Möglichkeit per Script herauszufinden was gerade vor sich geht: shutdown oder reboot? Dann könnte ich das beim Reboot dort abfangen.

Es funktioniert ja auch mit ExecStart nicht.

Ich habe jetzt einen *.desktop-Starter für mein Backup-Skript angelegt der zuerst die Sicherung durchführt und den PC anschließend herunterfährt. Anscheinend ist systemd nicht in der Lage das so zu machen wie ich es gerne hätte... Oder ich bin zu doof...

Wenn ich ExecStart weglasse oder nur ExecStart= schreibe, lässt sich der Service gar nicht starten.

Aber auch mit dem ExecStart funktioniert es nicht und wir wären damit dann wieder bei der Version und dem Problem aus dem Eingangspost...

Dank WantedBy=halt.target poweroff.target wird der Service nur beim Herunterfahren ausgeführt. In dem Fall zählt die Reihenfolge beim Starten nicht, oder doch? Und bei ExecStop ist auch nix eingetragen was auf dem Rückweg ausgeführt werden könnte.

EDIT:

[Unit]
Description=Data backup
DefaultDependencies=no
After=network.target
Conflicts=reboot.target


[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/pfad/zum/script.sh


[Install]
WantedBy=multi-user.target

Meinst du in der Art?

Wie das bei einem Service ist, der WantedBy=multi-user.target ist, habe ich (glaube ich) verstanden. Deinen Beitrag #9 hatte ich aber so gedeutet, dass dies hier nicht der richtige Weg ist, woraus dann die aktuelle Variante entstanden ist.

Ich habe aber nicht verstanden wie das mit einem Service funktioniert, der beim Herunterfahren ausgeführt wird, sprich dem jetzigen Zustand.

systemd-cat wäre eine richtige Variante hinsichtlich Logging, richtig?

Aus Running Services After the Network is up, Kapitel "Concepts in systemd" hätte ich egtl. herausgelesen, dass After=network.target genau das ist was ich brauche, aber das Netzwerk wird anscheinend deaktiviert bevor das Script ausgeführt wird. Wenn ich das After= in Before= ändere scheint das Verhalten aber exakt dasselbe zu sein.

[Unit]
Description=Data backup
DefaultDependencies=no
After=network.target
Conflicts=reboot.target


[Service]
Type=oneshot
ExecStart=/pfad/zum/script.sh


[Install]
WantedBy=halt.target poweroff.target

Zitat von Berichtigung

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.

Zitat von Berichtigung

Und verwende absolute Pfade.Statt date /bin/date.
Erst recht bei Testscripten

Was ist egtl. der Grund dafür? Gilt das allgemein für bash-Skripte oder speziell in Verbindung mit systemd?