Shutdown während aptitude upgrade verhindern

[FlorianK]

Situation:

Ein Debian "etch"-System wird per Skript mit aptitude aktuell gehalten. Das Skript wird bei jedem Systemstart ausgeführt und läuft unbemerkt im Hintergrund. Der Verlauf wird in einer seperaten log-Datei gespeichert.
Auf dem Rechner ist ein X-Server und die Gnome-Umgebung installiert. Er wird als ganz normaler Desktop-Rechner verwendet.


Problem:

Der Nutzer sieht optisch nichts vom gesammten Prozess. Dem zu Folge kann er nicht ohne betrachten der log-Datei feststellen, ob der Update-Vorgang bereits abgeschlossen ist, oder ob aptitude noch arbeitet.

Frage:

Was geschieht, wenn das System heruntergefahren wird, während aptitude neue Pakete installiert? Und wie könnte ich dies verhindern? Bzw. Den Nutzer daran hindern vor Ablauf des Skriptes den Rechner wieder herunterzufahren.

[pluvo]

Hallo!

Wo ist der ganze Nutzen? (Ich persönliche würde nie Updates automatisch einspielen lassen. Übrigens ist das eine schlechte Idee bei einem Desktop-System. Wenn der Benutzer gerade iceweasel benutzt und dieser im Hintergrund aktualisiert wird, kann das doch auch schief gehen.)

mfg pluvo

[rendegast]

Ein Skript aaaaaa als /etc/rc[5|6].d/K01aaaaaa verlinkt.
Das Skript prüft in einer Schleife auf ein Lockfile Deines Upgrade-Jobs oder ein 'pidof aptitude'.

Der Job könnte kurzfristig /sbin/shutdown die x-Bits nehmen oder rc5.d/ umbenennen.



EDIT ---------------------------------------------------------
Sorry, gemeint war
"als /etc/rc[0|6].d/K01aaaaaa verlinkt"
"oder rc[0|6].d/ umbenennen"

[Sid Burn]

Wenn der Benutzer gerade iceweasel benutzt und dieser im Hintergrund aktualisiert wird, kann das doch auch schief gehen.)

Nein, nicht wirklich, Debian ist ja keine Windows Distribution!

[cirrussc]

Wenn der Benutzer gerade iceweasel benutzt und dieser im Hintergrund aktualisiert wird, kann das doch auch schief gehen.)

Nein, nicht wirklich, Debian ist ja keine Windows Distribution!

Mit Iceweasel hatte ich bei einem Update auch noch keine Probleme aber kannst du das garantieren? Und beim Update von zentralen Bibliotheken würde ich sowieso nichts laufen lassen.

[pluvo]

Nein, nicht wirklich, Debian ist ja keine Windows Distribution!

Beim Update wird sogar darauf hingewiesen, dass man die iceweasel-Sitzung neustarten sollte (oder am besten gar keine Sitzung offen haben sollte?).

Das gilt aber auch noch für andere Dinge.

mfg pluvo

[Saxman]

Unter stable kann man gefahrlos auch im laufenden Betrieb updates installieren.
Einfach mal in der Doku nachlesen

9.2 Must I go into single user mode in order to upgrade a package?

No. Packages can be upgraded in place, even in running systems. Debian has a start-stop-daemon program that is invoked to stop, then restart running process if necessary during a package upgrade.

Alles andere ist ein Ammenmärchen.

Und wer SID oder testing benutzt sollte sowieso besser wissen was er macht..

Schönen Gruß

[FlorianK]

Vielen Dank für eure Antworten.

Der Einwand von pluvo ist berechtigt, auch wenn nicht zwangsläufig Probleme auftreten müssen. Ein anderes Problem wäre auch die Beantwortung spezieller Fragen, die während der Konfiguration neuer Paket-Updates sporadisch auftreten.

Abgesehen von der technischen Machbarkeit tritt aber ein weiteres Problem auf, welches ich bisher gar nicht bedacht habe. Und zwar die Bevormundung des Benutzers. Und das passt nicht zu Debian.
Ich werde das Skript wohl so abändern, dass zwar weiterhin bei jedem Systemstart nach neuen Updates gesucht wird, diese jedoch nicht installiert werden. Statt dessen soll der Benutzer eine Nachricht erhalten, in denen alle Updates aufgelistet sind.
Für die anschließende Installation überlege ich mir in den nächsten Tagen noch etwas.

[lemak]

Der Job könnte kurzfristig /sbin/shutdown die x-Bits nehmen...

Das ist ganz gut und so nahe liegend...

Ich werde das Skript wohl so abändern, dass zwar weiterhin bei jedem Systemstart nach neuen Updates gesucht wird, diese jedoch nicht installiert werden. Statt dessen soll der Benutzer eine Nachricht erhalten, in denen alle Updates aufgelistet sind.

Unter GNOME hat man das Paket update-manager das eigentlich genau das macht.

@FlorianK:
Vllt magst du dir diesen Wiki-Artikel anschauen und mit deinem Vorgehen vergleichen/verbessern.
http://wiki.debianforum.de/SoftwareVerw ... ts-upgrade

PS: Ein chmod -x /sbin/shutdown habe ich eingefügt.

EDIT:

Ein Skript aaaaaa als /etc/rc[5|6].d/K01aaaaaa verlinkt.
Das Skript prüft in einer Schleife auf ein Lockfile Deines Upgrade-Jobs oder ein 'pidof aptitude'.

Würde nach dem verlassen der Schleife der shutdown weiter ausgeführt, also der Rechner heruntergefahren (sicher ist es so)? In welchem Runlevel wäre es besser aufgehoben in 5 oder 6? Denn das wäre ja die bessere Entscheidung (mit einem lockfile).

[Sid Burn]

Wenn der Benutzer gerade iceweasel benutzt und dieser im Hintergrund aktualisiert wird, kann das doch auch schief gehen.)

Nein, nicht wirklich, Debian ist ja keine Windows Distribution!

Mit Iceweasel hatte ich bei einem Update auch noch keine Probleme aber kannst du das garantieren? Und beim Update von zentralen Bibliotheken würde ich sowieso nichts laufen lassen.

Jup, kann ich Garantieren da ich weiß wie das Dateisystem Funktioniert.

1) Programm A öffnet Datei oder Bibliothek X.
2) Du "löschst" Bibliothek X.
3) Programm A Interessiert es nicht da solange Bibliothek X als Dateihandle offen gehalten wird, die Datei weiterhin existiert und genutzt wird.
4) Solange irgendein Programm A Bibliothek X nutzt bleibt diese auch im Speicher vorhanden und wird weiter genutzt. Daher kannst du ja auch die libc im laufenden Betrieb updaten.
5) Programm A nutzt erst dann die neue Datei wenn du es schließt und neu öffnest.
6) Ein echtes Löschen gibt es eigentlich nicht unter Linux sondern nur das entfernen von Hardlinks. gelöscht wird eine Datei erst wenn Sie 0 hardlinks hat, oder keine Datei mehr offen gehalten wird.

Von daher kann der Updateprozess nicht wirklich fehlschlagen. Unter umständen könnte es in seltenen Fällen sein das Iceweasel nicht mehr Richtrig funktioniert, warum auch immer. Aber:
A) Ist das nicht der Update prozess
B) Kannst du Iceweasel eben schließen und neu starten und stellt nicht wirklich ein problem dar.

Ein anderes Problem wäre auch die Beantwortung spezieller Fragen, die während der Konfiguration neuer Paket-Updates sporadisch auftreten.

Und welches problem soll das genau darstellen? Das du sie evtl. nicht beantworten kannst?

[FlorianK]

@i:
Vielen Dank für den Link, an einen cronjob dachte ich jetzt eher nicht, aber die Idee mit "chmod -x" finde ich klasse.

@Sid Burn:

Und welches problem soll das genau darstellen? Das du sie evtl. nicht beantworten kannst?

Während des Update-Vorganges sieht man keine Konsole, man würde also von der Frage überhaupt nichts mitbekommen und das Skript würde nicht bis zum Ende durchlaufen.

[lemak]

Nun muss ich auch mal was Fragen:
Wenn man ein Paket installiert können ja Fragen auftauchen die nicht mit aptitude -y beantwortet werden zB. die SUN-JAVA Lizenz akzeptieren... - Klar.
Werden bei einem Update dann erneut Fragen gestellt? Kennt da jmd. Beispiele - Pakete?

Das würde ja bedeuten das Script verhindert in diesem Fall, das der Rechner ausgeschaltet werden kann.

[Sid Burn]

Während des Update-Vorganges sieht man keine Konsole, man würde also von der Frage überhaupt nichts mitbekommen und das Skript würde nicht bis zum Ende durchlaufen.

Mit "dpkg-reconfigure debconf" kannst du den Status Setzen ab welchen Grad du Benachrichtigt werden möchtest. Bzw. welches Frontend für die Fragen benutzt werden soll. Speziell dafür gibt es das Frontend "Noninteractive".

The editor frontend lets you configure things using your favorite text editor. The noninteractive frontend never asks you any questions.

[FlorianK]

Nun muss ich auch mal was Fragen:
Wenn man ein Paket installiert können ja Fragen auftauchen die nicht mit aptitude -y beantwortet werden zB. die SUN-JAVA Lizenz akzeptieren... - Klar.
Werden bei einem Update dann erneut Fragen gestellt? Kennt da jmd. Beispiele - Pakete?

Das würde ja bedeuten das Script verhindert in diesem Fall, das der Rechner ausgeschaltet werden kann.

Genau das ist mein Problem bei den Überlegungen

[FlorianK]

@i:

Der Link beantwortet unsere Frage

http://www.debiananwenderhandbuch.de/debconf.html

[lemak]

Der Link beantwortet unsere Frage
http://www.debiananwenderhandbuch.de/debconf.html

Super Sache

Code: Alles auswählen

export DEBIAN_FRONTEND=noninteractive
aptitude -y install sun-java6-jre sun-java6-plugin

Hier gibt es Probleme wegen der Lizenz muss man manuell installieren und dann bestätigen.
Aber so wird jedenfalls das Script beendet und einen Hinweis findet man dann in der log-Datei von dpkg - Sollte man ja mitbekommen wenn da was nicht funktioniert bzw. nicht vorhanden ist.
Bei Paketen wie tvtime funktioniert es aber wunderbar - Ich sag auch mal Danke.

[rendegast]

EDIT:

rendegast hat geschrieben:Ein Skript aaaaaa als /etc/rc[5|6].d/K01aaaaaa verlinkt.
Das Skript prüft in einer Schleife auf ein Lockfile Deines Upgrade-Jobs oder ein 'pidof aptitude'.


Würde nach dem verlassen der Schleife der shutdown weiter ausgeführt, also der Rechner heruntergefahren (sicher ist es so)? In welchem Runlevel wäre es besser aufgehoben in 5 oder 6?

Sorry, gemeint war /etc/rc[0|6].d/K01aaaaaa,
also STOP|RESTART.

[FlorianK]

Guten Morgen zusammen.

Das Skript habe ich nach den neusten Erkenntnissen abgeändert, bzw. erweitert. Anschließend habe ich interessehalber mit chmod -x dem Programm shutdown die Rechte zum Ausführen genommen und den Rechner versucht auszuschalten.

Ergebnis:

Unter Debian etch mit KDE lande ich am Anmeldeprompt der bash.

Unter Ubuntu 8.04 mit Gnome 2.22 lande ich am Anmeldefenster von Gnome. (Gnome startet sich hier anscheinend selbst neu)

Aber unter dem eigentlichen Zielrechner, Debian etch mit Gnome 2.14 erscheint nur eine Meldung im Sinne von "Der Rechner wird heruntergefahren..." und das war es dann.

Was genau geschieht, wenn man sich unter Gnome abmeldet und den Rechner neustartet oder ausschaltet weiß ich nicht, habe gestern auf die schnelle auch keine Konfigurationsdatei für Gnome gefunden, in der ich das nachschauen könnte.
Meine Vermutung ist, dass das System über ein Gnome-Skript in den runlevel 0 oder 6 geschaltet wird und die entsprechenden Aktionen durchgeführt werden.
Die Frage, die ich mir jetzt stelle und die mir hier vielleicht jemand beantworten kann ist:

Wenn etch in den runlevel 0 oder 6 schaltet, aber merkt, dass shutdown nicht ausführbar ist, "verharrt" es dann an diesem Punkt, oder versucht es in einer Schleife weiterhin shutdown auszuführen?
Wenn dem so wäre, dann müsste der Rechner nach Ablauf des Skriptes normal weiter runterfahren, oder neustarten.
Falls dem nicht so ist, wäre vielleicht eine andere Möglichkeit am Ende vom Skript routinemäßig den runlevel abzufragen und bei 0 oder 6 als Ergebnis den PC per Anweisung im Skript auszuschalten.

Wie verhält sich etch mit Gnome 2.14 denn bei euch, wenn ihr chmod -x /sbin/shutdown eingebt und versucht das System auszuschalten?

[finupsen]

Ein Skript aaaaaa als /etc/rc[5|6].d/K01aaaaaa verlinkt.
Das Skript prüft in einer Schleife auf ein Lockfile Deines Upgrade-Jobs oder ein 'pidof aptitude'.

Der Job könnte kurzfristig /sbin/shutdown die x-Bits nehmen oder rc5.d/ umbenennen.



EDIT ---------------------------------------------------------
Sorry, gemeint war
"als /etc/rc[0|6].d/K01aaaaaa verlinkt"
"oder rc[0|6].d/ umbenennen"

kleine ergänzung:

evtl. könnte man auch ein wrapper-script vor "shutdown" setzen. Ansonsten wie
@rendegast beschrieben: pid/lock prüfen und bei false mit "$@" durchreichen.

@FlorianK
hier ein beispiel:

Code: Alles auswählen

#/bin/bash
ps -eo "%a"|grep -q xcalc >/dev/null 2>&1;X=$?
if [ $X -eq 1 ];then
   bash -c "/bin/ls $@"
fi

"ls" wird ausgeführt wenn kein "xcalc" läuft. Musste nur anpassen...

[FlorianK]

Hallo zusammen,

ich habe es zum laufen gebracht! Oder anders gesagt, es sind mir keine weiteren Fehler mehr aufgefallen.

Für alle, die es interessiert, hier das erwähnte Skript zum automatischen updaten des Systems:

http://nopaste.debianforum.de/10238

Es sind noch kleine Verbesserungen zu erledigen. Die Varibable TEMPFILE z.B. ist unnötig, da sed die Quelldatei auch selbst überschreiben kann. Das ändere ich dann noch, bin aber froh, dass es überhaupt läuft.

[rendegast]

Die Varibable TEMPFILE z.B. ist unnötig, da sed die Quelldatei auch selbst überschreiben kann.

Meinst Du in der Art 'sed ... FILE > FILE' ?
Genau so sollte es nicht sein.

Eine Alternative:

Code: Alles auswählen

/etc/fstab :
tmpfs           /tmp            tmpfs   auto,async      0       0

Im Skript:
TMPFILE=`mktemp /tmp/tmpfile.XXXX`

[Lohengrin]

ich habe es zum laufen gebracht! Oder anders gesagt, es sind mir keine weiteren Fehler mehr aufgefallen.

Für alle, die es interessiert, hier das erwähnte Skript zum automatischen updaten des Systems:

http://nopaste.debianforum.de/10238

Es sind noch kleine Verbesserungen zu erledigen. Die Varibable TEMPFILE z.B. ist unnötig, da sed die Quelldatei auch selbst überschreiben kann. Das ändere ich dann noch, bin aber froh, dass es überhaupt läuft.

Es wäre noch schön, wenn der Benutzer darüber informiert wird, dass da ein Upgrade gemacht wird. Am Besten mit Vorwarnung und Frage soll ich das tun?.
Wenn ich meinen Rechner runterfahren will, und das Ding nicht ausgeht, dann ziehe ich den Netzstecker.

[FlorianK]

@ rendegast:

Nein ich meinte die Option "-i" von sed.

@Lohengrin:

Im Prinzip hast du recht. Aber in meinem Fall möchte die Person nicht jedes mal bestätigen müssen. Eine kurze Benachrichtigung wäre aber dennoch eleganter. Mal sehen, wie ich das hinbekomme.