BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
Hallo, früher gabs für sowas ja rc.local und cron undsoweiter. Jetzt also mit systemd. Ich will also nach Starten des Rechners ein Backup-Skript ausführen und anschließend den Rechner automatisiert wieder runter fahren. Theorie:
Service-Typ oneshot (siehe systemd/Service Units (Abschnitt „Service-Typen“)), um zu verhindern, dass das Skript mehrfach läuft im Skript dann ein sleep mit 5min vor dem eigentlichen Task Abhängigkeiten wie mounts lassen sich ja mit systemd easy machen
Frage: Bei den systemd/Timer Units gibt es OnBootSec . Das klingt ganz nett, allerdings muss ich ja dann eine Service Unit und eine Timer Unit anlegen, weil ich das Skript nicht direkt in die Timer Unit packen kann - hier muss ja die Service Unit rein. Hat das irgendwelche Vorteile? Fällt euch sonst noch was ein, was es zu beachten gilt? Gruß BillMaier Ps. Muss das morgen hier fertig machen und bin dann längere Zeit nicht an dem Rechner, kann also nicht wirklich nacharbeiten - deshalb frag ich hier schon mal nach Stolpersteinen. Man muss ja nicht alle Fehler selbst machen 😉
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29065
Wohnort: WW
|
Hallo, Timer Units starten immer Service Units, so dass Konzept. Vorteil ist, dass der Time vom Skript entkoppelt ist und mehrere Timer ggf. die gleiche Unit starten können. Wobei das bei cron ja nicht anders ist: cron überwacht das Timing und führt dann ein Skript aus. Gruß, noisefloor
|
BillMaier
Supporter
(Themenstarter)
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
Hallo und danke für die Info. noisefloor schrieb: Vorteil ist, dass der Time vom Skript entkoppelt ist und mehrere Timer ggf. die gleiche Unit starten können.
Daraus schließe ich: Wenn ich das nicht brauche, habe ich keinen wirklichen Vorteil. Dann probier ich es erstmal so. Vielen Dank! Gruß BillMaier
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
BillMaier schrieb:
Diese Bedeutung hat oneshot nicht, die Unit wird sowieso nur einmal gestartet. Oneshot hat zur Konsequenz, dass Folge-Units erst bearbeitet werden, wenn diese Unit erfolgreich gestartet wurde und der Prozess zurückgekehrt ist, und dass innerhalb max. 90 Sekunden. Du musst also daran denken, dass die Unit und das gestartete Programm nach 90 Sekunden gekillt werden, weil systemd dann -völlig korrekt- davon ausgeht, dass das Programm gestorben ist, falls das Backup länger dauern würde. Die Lösung, Du startest besser von der Unit nur ein Init-Script, was das eigentliche Backup als Background-Prozess startet (oder sich selber wegforkt) und dann selber sofort mit einem "exit 0" zurückkehrt, während im Hintergrund das Backup laufen kann. Wenn es sich wegforkt wäre simple der bessere Unit-Type. BTW, der 90-Sec-Timeout gilt für alle Unit-Types. Ich würde dann im eigentlichen Backup-Script einen "sleep 300" an den Anfang stellen, dann hast Du auf ganz einfache Weise deine 5 Minuten Wartezeit. Also ungefähr so:
| #!/bin/bash
Backupd()
{
sleep 300
rsync a nach b
exit 0
}
Backupd &
exit 0
|
|
BillMaier
Supporter
(Themenstarter)
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
TomLu schrieb: Ich würde dann im eigentlichen Backup-Script einen "sleep 300" an den Anfang stellen, dann hast Du auf ganz einfache Weise deine 5 Minuten Wartezeit.
Genau. Oder die Minuten mit angeben, dann kann man auch 5 schreiben 😉 Danke für deine Ergänzung zu oneshot bzw. der 90 Sekunden. Das ist mir tatsächlich neu. Gibt es keinen Typ, den ich - ohne ein weg-forken - nutzen kann und es keinen Timeout von 90Sekunden gibt? (Hab das jetzt auf morgen Vormittag verschoben, klappt heute nicht mehr, danach sollte das aber eigentlich tun...) Ps. It is generally recommended to use Type=simple for long-running services whenever possible, as it is the simplest and fastest option. Also doch simple?
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
BillMaier schrieb: Gibt es keinen Typ, den ich - ohne ein weg-forken - nutzen kann und es keinen Timeout von 90Sekunden gibt?
Nö, gibts nicht...die 90 Sekunden sind fest... was auch wirklich sinnvoll ist. es ist Aufgabe des systemmanagers darauf zu achten, dass gestorbene Prozesse nicht das System stören oder was anderes blockieren. Das ist aber kein echtes Problem. Und ja, ich würde simple nehmen.... und das Backup in den Hintergrund stellen, wie oben im Beispiel: Und ich würde im Script durchaus viele solcher Nachrichten-Statements setzen... dann kannst Du den ganzen Prozess prima via journalctl verfolgen. echo "hier ist eine Meldung" | systemd-cat -t "$(basename $0)" -p "info"
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
vertan,vertan sprach...
sorry
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
TomLu schrieb: BillMaier schrieb: Gibt es keinen Typ, den ich - ohne ein weg-forken - nutzen kann und es keinen Timeout von 90Sekunden gibt?
Nö, gibts nicht...die 90 Sekunden sind fest...
TimeoutStartSec ist durchaus konfigurierbar: https://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutStartSec= - eigentlich greift das standardmäßig auch nur bei Service Typen, bei denen ein Signal vom Dienst erwartet wird, dass er einen betriebsbereiten Zustand erreicht hat (also Type=dbus, notify oder forking).
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
seahawk1986 schrieb: TimeoutStartSec ist durchaus konfigurierbar: [https://www.freedesktop.org/software/systemd
Ja, das weiss ich, nur würde ich das für ein Backup, dessen Dauer (wenns möglicherweise auch noch übers Netz geht) ggf. unkalkulierbar ist, niemals empfehlen. Wenn ich wüsste, der Job kommt vielleicht mit 90 Sec. nicht hin, braucht aber garantiert keine 3 Minuten, dann würde ich vielleicht darüber nachdenken, den Timeout zu verdoppeln.... womit aber meine Schmerzgrenze definitiv erreicht wäre. Fakt ist, ein falscher Parameter und ein gestorbener resp. aufgehängter Prozess können einen ordnungsgemäßen Reboot verhindern. Ich denke dazu, schlechter kann man ein Problem nicht lösen. Ich würde den Timeout belassen, wie er ist und eben den Startvorgang des Jobs und den Job selber so gestalten, dass er in der Überwachung des systemmanagers und dessen Default-Einstellungen ist. Bei der Planung und Konzeption eines neuen Jobs sehe ich jedenfalls keinen vernünftigen Grund,an solchen Schrauben zu drehen und würde das auch nicht tun. Das ist aber nur meine Meinung, die man ja nicht teilen muss....
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
TimeoutStartSec kommt normalerweise gar nicht erst ins Spiel, wenn Type=simple oder Type=oneshot gesetzt ist.
Das Backup selber kann man mit systemd-inhibit schützen, wenn das nicht unterbrochen werden soll (es sei denn der Admin erzwingt da in der Zwischenzeit einen Shutdown/Reboot). Dadurch kommt man hoffentlich nicht in die Verlegenheit, dass TimeoutStopSec relevant wird. Und wenn das Backup durch ist, kann das Skript es den Shutdown selbst anstoßen. | #!/bin/sh
systemd-inhibit \
--who "My Backup Script" \
--why "It's a stupid idea to make an incomplete backup" \
--what shutdown:sleep:idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
--mode block \
rsync a nach b
systemctl poweroff ||: # do nothing if another shutdown inhibitor is set
|
|
BillMaier
Supporter
(Themenstarter)
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
|