[solved] Script beim Herunterfahren ausführen

[sorcim]

Hallo,

Ich möchte ein Script einrichten, welches beim Herunterfahren ausgeführt wird. Nun bin ich mir nicht ganz sicher, ob ich das richtig verstanden habe, darum frag ich nochmal nach:

1. Ich erstelle ein Script in /etc/init.d
2. Ich verlinke dieses Script in /etc/rc0.d mit dateinamen S01*

Jetzt wäre die Frage, ob der Shutdown solange wartet, bis alle Befehle in dem Script ausgeführt UND BEENDET wurden. Wenn ich in meinen Fall Unison in dem Script aufrufe, kann das ja ein bisschen dauern, bis das durchgelaufen ist. Wartet der Shutdown-Prozess also?

Spricht denn außerdem was dagegen, beim Shutdown ein automatisches Update (apt-get update && apt-get dist-upgrade) durchzuführen?

Vielen Dank für eure Anregungen,
Tobias

[pferdefreund]

Eventuell userbezogen machen. Wie meldest du dich denn an - gleich grafisch per gdm oder so oder nur Konsole und danns startx ?
Wenn erst per Konsole, dann ggf script in .batch-logout packen und um shutdown -h now ergänzen - ggf noch per sudo die Berechtigung für shutdown setzen.

[Meillo]

Ich möchte ein Script einrichten, welches beim Herunterfahren ausgeführt wird. Nun bin ich mir nicht ganz sicher, ob ich das richtig verstanden habe, darum frag ich nochmal nach:

1. Ich erstelle ein Script in /etc/init.d
2. Ich verlinke dieses Script in /etc/rc0.d mit dateinamen S01*

Nach meinem Verstaendnis ist das so angemessen.

Jetzt wäre die Frage, ob der Shutdown solange wartet, bis alle Befehle in dem Script ausgeführt UND BEENDET wurden. Wenn ich in meinen Fall Unison in dem Script aufrufe, kann das ja ein bisschen dauern, bis das durchgelaufen ist. Wartet der Shutdown-Prozess also?

Was spricht gegen einen einfachen Test mit `sleep 60'?

Spricht denn außerdem was dagegen, beim Shutdown ein automatisches Update (apt-get update && apt-get dist-upgrade) durchzuführen?

Ja! Ein dist-upgrade ist kein automatischer Vorgang. Sowas wuerde ich nicht komplett unbeaufsichtigt machen. Auch ist mir das dist-upgrade als Ersatz fuer das upgrade suspekt. Nach meinem Verstaendnis sollte man nur bewusst dist-upgraden, sonst aber normal upgraden.

[Meillo]

Wenn erst per Konsole, dann ggf script in .batch-logout packen und um shutdown -h now ergänzen

Aber nur in der Kombination. Denn ein Shutdown killt (nach einer Vorwarnung) dein .bash_logout-Script. Ich denke, dieser Ansatz ist nur fuer spezielle Faelle geeignet.

[sorcim]

Also ich melde mich graphisch per gdm an.

Der 'sleep 60' Test war leider nicht erfolgreich; allerdings habe ich auch ein fach nur diesen Befehl in eine #!/bin/bash Datei eingefügt; es gibt ja anscheinend noch diese LSBInitScripts (https://wiki.debian.org/LSBInitScripts) , bei denen man irgendwie facilities festlegen kann, die für das Script benötigt werden. Im Prinzip glaub ich das einigermaßen verstanden zu haben, aber welche facilities sind hier denn möglich? Nur $remote_fs $local_fs und $network reicht ja nicht.... ich brauch ja beispielsweise noch den ssh daemon.

Also so ganz nen Plan, wie ich das umsetze hab ich leider nohc nicht -_-

Das ist übrigens für meine Eltern als automatisches Backup auf einen Homeserver geplant und sollte deshalb möglichst reibungslos laufen.

EDIT: Ach quatsch; den ssh Daemon brauch ich ja nur auf dem Server... dann werd ich das gleich mal so versuchen!

[dirk11]

Ich möchte ein Script einrichten, welches beim Herunterfahren ausgeführt wird. Nun bin ich mir nicht ganz sicher, ob ich das richtig verstanden habe, darum frag ich nochmal nach:
1. Ich erstelle ein Script in /etc/init.d
2. Ich verlinke dieses Script in /etc/rc0.d mit dateinamen S01*

Nach meinem Verstaendnis ist das so angemessen.

Nein. Scripte, die beim Herunterfahren ausgeführt werden sollen, benennt man mit Kxx-irgendwas. Ebenso muss man das Script noch in die files .depend.boot .depend.start und .depend.stop in ebendiesem Verzeichnis /etc/init.d eintragen (seit Wheezy).

[sorcim]

So, ich denke dann, dass ich das jetzt hinbekommen habe.

Wie sieht das denn mit normalen updates aus (also statt dist-upgrade nur upgrades)? Kann ich die automatisiert beim beenden machen?

LG,
Tobias

[smutbert]

Nein. Scripte, die beim Herunterfahren ausgeführt werden sollen, benennt man mit Kxx-irgendwas. […]

Moment, das stimmt jetzt aber nicht ganz, oder?

Links zu Skripten die mit Sxx… benannt sind, werden mit dem start parameter aufgerufen, die zugehörigen Dienste im allgemeinen also beim Wechsel in den jeweiligen Runlevel gestartet.

Bei Kxx… dagegen werden die Skripte mit dem Parameter stop aufgerufen, was den zughörigen Dienst beenden soll.

mountall z.B. das beim Starten die Dateisysteme in der fstab mountet ist lediglich mit S09mountall für den runlevel S verlinkt, weil es nur einmal beim Systemstart gestartet und in keiner Weise wieder "beendet" werden soll. Dementsprechend hielte ich die Vorgehensweise ein Startskript zu schreiben und für runlevel 0 mit Sxx… zu verlinken für durchaus sinnvoll und richtig.

[dirk11]

Stimmt auch. Irgendwie. Und irgendwie wieder nicht. Scripte, die zum Beenden ausgeführt werden, heissen nunmal K..., die führen ja nicht alle nur ein killall ... aus. Und rcS wird nur beim Start ausgeführt.
Außerdem werden Scripte, die beim Herunterfahren benötigt werden, mit K ausgeführt, die beim Hochfahren mit S. Wie sonst willst Du Start- und Ende-Scripte sinnvoll unterscheiden?

[Meillo]

Die S-Scripte (mit Argument `start') werden beim Eintritt in einen Runlevel ausgefuehrt werden und die K-Scripte (mit Argument `stop') beim Austritt.

Wenn ich nun einen Shutdown durchfuehre, entspricht das dem Wechsel vom Runlevel 2 ins Runlevel 0. Damit werden sowohl die Scripte /etc/rc2.d/K* ausgefuehrt als auch (danach) die Scripte /etc/rc0.d/S*, nur halt mit verschiedenem Argument.

Es ist also technisch beides moeglich. Die Frage ist also nur, was man logischer findet ... und das ist halt Ansichtssache.

[smutbert]

Wie käme es dann überhaupt jemals zur Ausführung der Killskripte in rc0.d (dort liegen zB. K09umountroot und K10halt)

Ich hatte ja vermutet, dass beim Wechsel von Runlevel A zu runlevel B, alle
- Stoppskripte in rcB.d und
- Startskripte in rcB.d ausgeführt werden
liege ich damit wirklich daneben (bis jetzt hat sich mir diese Frage interessanterweise noch nie gestellt)

Außerdem liegen die ganzen Killskripte für die Dienste (ssh, pulseaudio, gdm3, bluetooth, mpd,…) in rc0.d und kein einziges in rc2.d und doch werden die Dienste beim herunterfahren gestoppt. Das spricht doch auch für meine Theorie.

(bitte entschuldigte Meillo, ich will nicht rechthaberisch sein, aber wenn ich nach all den Jahren mit Debian das Gefühl habe das womöglich bald nicht mehr aktuelle init system durchschaut zu haben, interessiert es mich doch ob ich womöglich einem kapitalen Irrtum aufgesessen bin…)

[Meillo]

Ich hatte ja vermutet, dass beim Wechsel von Runlevel A zu runlevel B, alle
- Stoppskripte in rcB.d und
- Startskripte in rcB.d ausgeführt werden
liege ich damit wirklich daneben

Nein. Du liegst sogar genau richtig. Ich lag falsch.

Ich habe jetzt nachgelesen (wie man das immer tun sollte bevor man altklug daher redet ):

3. Switching runlevels.

When one switches from (for example) runlevel 2 to runlevel 3,
/etc/init.d/rc will first execute in alphabetical order all K
scripts for runlevel 3 (/etc/rc3.d/KXXxxxx) with as first argument
"stop" and then all S scripts for runlevel 3 (/etc/rc3.d/SXXxxxx)
with as first argument "start".

Somit ware wohl /etc/rc0.d/S* der richtige Ort, wuerde ich sagen.

(bitte entschuldigte Meillo, ich will nicht rechthaberisch sein, aber wenn ich nach all den Jahren mit Debian das Gefühl habe das womöglich bald nicht mehr aktuelle init system durchschaut zu haben, interessiert es mich doch ob ich womöglich einem kapitalen Irrtum aufgesessen bin…)

Das hat nichts mit Rechthaberei zu tun und schon gar nicht mit dem ``Status'' von manchen Usern. Du hast schlichtweg Recht und ich habe geschlampt. Da waere es schlimm gewesen, wenn du nicht den Mund aufgemacht haettest.

[dirk11]

3. Switching runlevels.

When one switches from (for example) runlevel 2 to runlevel 3,
/etc/init.d/rc will first execute in alphabetical order all K
scripts for runlevel 3 (/etc/rc3.d/KXXxxxx) with as first argument
"stop" and then all S scripts for runlevel 3 (/etc/rc3.d/SXXxxxx)
with as first argument "start".

Somit ware wohl /etc/rc0.d/S* der richtige Ort, wuerde ich sagen.

Nö, nicht ganz. Dann ist es ja nur noch eine Definitionsfrage. Es soll ja ein Script ausgeführt werden, jetzt kann man sich das ja selbst definieren, ob es seine Aktion als Kxx und "stop" ausführt oder als Sxx und mit "start". Ich würde ersteres nehmen, weil es für mich logischer klingt. "stop" heisst für mich nicht unbedingt, das etwas angehalten wird, sondern das eine bestimmte Aktion auf die Meldung "stop" ausgeführt wird. Ich würde es also auch nach rc0.d stecken, dort aber als Kxx irgendwo zwischen den anderen Ks ausführen, denn das Script wird zwar einerseits zum "Start" des "Runlevel 0" ausgeführt, aber da Runlevel 0 = Ausschalten bedeutet, würde ich es für mich als zum "Stop" des Systems gehörig definieren.

[smutbert]

Danke Meillo und auch an alle anderen.

Jetzt ist aber auch klar, dass und warum mein Vorschlag, das Skript als Startskript in rc0.d zu verlinken komplett falsch war:

Die Killskripte werden vor den Startskripten ausgeführt, aber das letzte Killskript auf einem (Debian) System ist K10halt und init dürfte sich mit dem Starten der Sxx Skripte aus rc0.d bei bereits ausgeschaltetem Rechner etwas schwer tun

[dirk11]

das letzte Killskript auf einem (Debian) System ist K10halt und init dürfte sich mit dem Starten der Sxx Skripte aus rc0.d bei bereits ausgeschaltetem Rechner etwas schwer tun

Stimmt auffallend Also als K09 ausführen - oder eher, je nachdem, ob noch irgendwelche Dienste laufend benötigt werden.

[Meillo]

das letzte Killskript auf einem (Debian) System ist K10halt und init dürfte sich mit dem Starten der Sxx Skripte aus rc0.d bei bereits ausgeschaltetem Rechner etwas schwer tun

Stimmt auffallend Also als K09 ausführen - oder eher, je nachdem, ob noch irgendwelche Dienste laufend benötigt werden.

Ah, natuerlich!

Wobei ich das als Ausnahme im Runlevel 0 sehe.

So wie ich das verstanden habe, wird fuer einen Service in allen Runleveln in denen er laufen soll ein S-Script angelegt und in allen anderen ein K-Script. Ein K-Script bedeutet also, dass dieser Service in diesem Runlevel nicht laufen soll. Das Autobackup im vorliegenden Beispiel verstehe ich als Service, der im Runlevel 0 laufen soll. Ich wuerde aber auch K10halt als S10halt in rc0.d ablegen, dafuer alle sonstigen Services als K-Scripte dort hinterlegen. Was waere IMO vom Konzept stimmiger.

Oder fehlt mir schon wieder eine Information?

[dirk11]

Oder fehlt mir schon wieder eine Information?

Das glaube ich nicht. Aber du wirst es wohl so hinnehmen müssen, wie die Entwickler sich das vorgestellt haben. Und deren Konzept funktioniert, das kann man täglich erleben. Also leg den Script einfach mit nem Symlink K09 ab und gut ist.

[sorcim]

Bei mir geht jetzt übrigens alles problemlos p

Danke für eure Hilfe!