Ubuntu: Hängenden umount entfernen

[Andreas Kohlbach]

Mir blockiert hier ein hängender "umount" den Reboot.
-$ ps aux | grep umount
root 28214 [..] umount /tmp/tmp.CNzSVjYEgH
Das Verzeichnis gibt es aber nicht mehr, hängt also in der Luft.
~$ fuser /tmp/tmp.CNzSVjYEgH
Kann Status von "/tmp/tmp.CNzSVjYEgH" nicht ermitteln: No such file or
directory

Hast du da einen Zombie (ps ax müsste das anzeigen)?

Der Rechner sitzt am anderen Ende der Welt, in den nächsten Tagen
kommt da keiner hin zum Stecker ziehen.
Was tun? Ich kann noch per SSH zugreifen.

Vermutlich nichts. Ich hatte das mit dem mount auch mal, und es wurde ein
Zombie oder zumindest "D", und auch nach Stunden änderte sich
nichts. Auch kill -9 half nicht.

[Juergen Ilse]

Hallo,

Post by Andreas Kohlbach
Vermutlich nichts. Ich hatte das mit dem mount auch mal, und es wurde ein
Zombie oder zumindest "D", und auch nach Stunden änderte sich
nichts. Auch kill -9 half nicht.

"Zombie" und "Prozess im uniterruptable Sleep" sind aber sehr unterschied-
liche Dinge: Ein "Zombie" ist ein "toter Prozess", der ausser dem Eintrag
in der Prozesstabelle keinerlei Resourcen mehr belegt. Er entsteht, wenn
sich ein Prozess beendet aber der Parent-Prozess nicht mittels "wait" den
Exitstatus abfragt. Ein Prozess im Status "D" ist dagegen im "uinterruptable
Sleep": i.d.R. haengt er in einem Aufruf einer Kernelfunktion, die nicht
unterbrechbar ist aber z.B. aufgrund von Fehlern (warten auf belegte Re-
sourcen oder dergleichen) nicht beendet werden kann. Der Prozess ist zwar
noch irgendwie "am Leben" aber kann nicht mehr beeinflusst werden: Auch
Signale erreichen den Prozess erst, wenn jene "nicht unterbrechbare Funk-
tion" beendet wurde. Wenn so etwas passiert, wird man den haengenden Pro-
zess evt. nur durch einen reboot los ... Ganz im Gegensatz zum Zombie, den
man i.d.R. loswerden kann, wenn man seinen Parent killed (dann erbt init
den Porzess, und init hat dann die Aufgabe, auf seine ganzen Kinderchen
zu warten, was es auch normalerweise prompt erledigt, wodurch dann der
Zombie verschwindet).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Ansgar Strickerschmidt]

Ein Prozess im Status "D" ist dagegen im "uninterruptable Sleep": i.d.R.
haengt er in einem Aufruf einer Kernelfunktion, die nicht
unterbrechbar ist aber z.B. aufgrund von Fehlern (warten auf belegte Re-
sourcen oder dergleichen) nicht beendet werden kann. Der Prozess ist zwar
noch irgendwie "am Leben" aber kann nicht mehr beeinflusst werden: Auch
Signale erreichen den Prozess erst, wenn jene "nicht unterbrechbare Funk-
tion" beendet wurde. Wenn so etwas passiert, wird man den haengenden Pro-
zess evt. nur durch einen reboot los ...

Wieder was fürs Leben gelernt. :)
(Ich muss unserem Server daraufhin mal auf den Zahn fühlen... ich fürchte,
sowas passiert ab und zu beim Lauf des Backup-Tools hier. Was soll's -
demnächst wird das Teil eh einem vernünftigen und modernen NAS mit
gescheiter Sicherungsstrategie weichen.)

Ansgar

[Bernd Hohmann]

Post by Juergen Ilse
"Zombie" und "Prozess im uniterruptable Sleep" sind aber sehr unterschied-
liche Dinge: [...] Ein Prozess im Status "D" ist dagegen im "uinterruptable

Ja, der ubount sitzt auf "D<"

~$ ps aux | grep umount
root 28214 0.0 0.0 7320 784 ? D< 02:19 0:00 umount /tmp/tmp.CNzSVjYEgH

Post by Juergen Ilse
Wenn so etwas passiert, wird man den haengenden Prozess evt. nur durch
einen reboot los ...

Und da ist der Haken: der Reboot (reboot -f 0) wird von diesem hängenden
umount blockiert.

Irgendwelche Ideen wie ich via SSH die Kiste trotzdem zum Reboot bekomme?

Bernd

[Hauke Laging]

Post by Bernd Hohmann
Und da ist der Haken: der Reboot (reboot -f 0) wird von diesem
hängenden umount blockiert.

Das wundert mich. Kannst ja mal mit strace schauen, an welcher Stelle
reboot nicht weiterkommt.

Statt dessen vielleicht mal init 6?

Post by Bernd Hohmann
Irgendwelche Ideen wie ich via SSH die Kiste trotzdem zum Reboot bekomme?

Nur eine brutale (OK, anderes steht wohl eh nicht mehr zur Wahl), nie
selber ausprobierte: man kexec

Das hilft natürlich nur dann, wenn nur der Treiber verreckt ist,
nicht aber die zugehörige Hardware, denn die bekommt bei der Aktion
keinen Reset AFAIK.


CU

Hauke

[Bernd Hohmann]

Post by Hauke Laging

Post by Bernd Hohmann
Und da ist der Haken: der Reboot (reboot -f 0) wird von diesem
hängenden umount blockiert.

Das wundert mich. Kannst ja mal mit strace schauen, an welcher Stelle
reboot nicht weiterkommt.

gute idee: er hängt beim "sync", den kann er wegen dem hängenden
"umount" nicht durchführen.

Post by Hauke Laging
Statt dessen vielleicht mal init 6?

Geht nicht.

Post by Hauke Laging

Post by Bernd Hohmann
Irgendwelche Ideen wie ich via SSH die Kiste trotzdem zum Reboot bekomme?

Nur eine brutale (OK, anderes steht wohl eh nicht mehr zur Wahl), nie
selber ausprobierte: man kexec

kexec -l /boot/vmlinuz-2.6.28-16-server
'--append=root=UUID=294210a5-9c0a-4e0c-a896-7ca8884733d6 ro quiet splash

Hängt genauso in der Luft.

Bernd

[Michael Baeuerle]

Post by Bernd Hohmann

Post by Hauke Laging
Das wundert mich. Kannst ja mal mit strace schauen, an welcher Stelle
reboot nicht weiterkommt.

gute idee: er hängt beim "sync", den kann er wegen dem hängenden
"umount" nicht durchführen.

Laut manpage gibt es "-n" um den sync zu unterdruecken, also:
---------------
reboot -n -f
---------------
koennte helfen wenn der Kernel nicht selber noch irgendwo sync macht.


Micha

[Bernd Hohmann]

Post by Michael Baeuerle

Post by Bernd Hohmann
gute idee: er hängt beim "sync", den kann er wegen dem hängenden
"umount" nicht durchführen.

---------------
reboot -n -f
---------------
koennte helfen wenn der Kernel nicht selber noch irgendwo sync macht.

Mensch - auf die einfachsten Sachen kommt man zuletzt :-)

Die Buschtrommel läuft wieder, danke!

Bernd

[Andreas Kohlbach]

Post by Michael Baeuerle
---------------
reboot -n -f
---------------
koennte helfen wenn der Kernel nicht selber noch irgendwo sync macht.

Ich finde weder in der reboot-, noch shutdown man Page einen "-n", weiß
aber, dass ich den auch mal benutzte.

[Martin Schmitz]

Post by Andreas Kohlbach

Post by Michael Baeuerle
---------------
reboot -n -f
---------------
koennte helfen wenn der Kernel nicht selber noch irgendwo sync macht.

Ich finde weder in der reboot-, noch shutdown man Page einen "-n",
weiß aber, dass ich den auch mal benutzte.

Debian oder -Derivat? Da sind selbst die Manpages kaputt, also besser
Google nach Anleitungen fragen.

Martin

[Manfred Schmitt]

Post by Martin Schmitz

Post by Andreas Kohlbach
Ich finde weder in der reboot-, noch shutdown man Page einen "-n",
weiß aber, dass ich den auch mal benutzte.

Debian oder -Derivat? Da sind selbst die Manpages kaputt, also besser
Google nach Anleitungen fragen.

Muss ich mir Sorgen machen wenn -n unter Debian Lenny (und auch Etch)
in der manpage drin steht? ;)

Und wech,
Manne

[Bernd Hohmann]

Post by Andreas Kohlbach

Post by Michael Baeuerle
---------------
reboot -n -f
---------------
koennte helfen wenn der Kernel nicht selber noch irgendwo sync macht.

Ich finde weder in der reboot-, noch shutdown man Page einen "-n", weiß
aber, dass ich den auch mal benutzte.

Scheint Ubuntu-Spezifisch zu sein.

-n Does not call sync(2) before performing the reboot; this could
result in data loss. On Linux, this probably has no effect as
the kernel flushes all write buffers before shutting down.

REPORTING BUGS
Report bugs at https://launchpad.net/products/upstart/+bugs

COPYRIGHT
Copyright © 2007 Canonical Ltd.

Das im Ubuntu verwendete Konstrukt läuft jedenfalls im "reboot -f" durch
ein "sync" (siehe mein Posting irgendwo vorher).

Bernd

[Hauke Laging]

Post by Bernd Hohmann
Scheint Ubuntu-Spezifisch zu sein.

Nein (hier openSUSE; steht seit 9.3 in der man page).


CU

Hauke

[Helmut Hullen]

Hallo, Andreas,

Post by Andreas Kohlbach

Post by Michael Baeuerle
---------------
reboot -n -f

Ich finde weder in der reboot-, noch shutdown man Page einen "-n",
weiß aber, dass ich den auch mal benutzte.

Slackware: "man reboot" führt zu "man 8 halt", und da ist u.a. die
Option "-n" erwähnt. Manpage vom 6. November 2001.

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Helmut Hullen]

Hallo, Bernd,

Post by Bernd Hohmann
Und da ist der Haken: der Reboot (reboot -f 0) wird von diesem
hängenden umount blockiert.
Irgendwelche Ideen wie ich via SSH die Kiste trotzdem zum Reboot bekomme?

Unabhängig von dem hängenden "umount": so etwas pflege ich per

echo "reboot" | at now + 10 minutes

einzuplanen, und dann logge ich mich rechtzeitig vorher aus.

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Torsten Fleischmann]

Post by Helmut Hullen
Hallo, Bernd,

Merkwürdige Einleitungszeile...

Post by Helmut Hullen

Post by Bernd Hohmann
Und da ist der Haken: der Reboot (reboot -f 0) wird von diesem
hängenden umount blockiert.
Irgendwelche Ideen wie ich via SSH die Kiste trotzdem zum Reboot bekomme?

Unabhängig von dem hängenden "umount": so etwas pflege ich per
echo "reboot" | at now + 10 minutes
einzuplanen, und dann logge ich mich rechtzeitig vorher aus.

Warum willst du dich vorher ausloggen? Einfach reboot reicht doch aus.

[Martin Schmitz]

Post by Helmut Hullen
Unabhängig von dem hängenden "umount": so etwas pflege ich per
echo "reboot" | at now + 10 minutes
einzuplanen, und dann logge ich mich rechtzeitig vorher aus.

Und wozu soll das gut sein?

Martin

[Bernd Hohmann]

Post by Martin Schmitz

Post by Helmut Hullen
Unabhängig von dem hängenden "umount": so etwas pflege ich per
echo "reboot" | at now + 10 minutes
einzuplanen, und dann logge ich mich rechtzeitig vorher aus.

Und wozu soll das gut sein?

Gut dass Du fragst, das wollte ich nämlich auch bei Helmut nachhaken. So
auf den ersten Blick habe ich gedacht dass da ein Reboot angeschmissen
wird wenn man in 10min immer noch drin ist (was manchmal nützlich wäre).

Bernd

[Helmut Hullen]

Hallo, Bernd,

Post by Bernd Hohmann

Post by Martin Schmitz

Post by Helmut Hullen
Unabhängig von dem hängenden "umount": so etwas pflege ich per
echo "reboot" | at now + 10 minutes
einzuplanen, und dann logge ich mich rechtzeitig vorher aus.

Und wozu soll das gut sein?

Gut dass Du fragst, das wollte ich nämlich auch bei Helmut nachhaken.
So auf den ersten Blick habe ich gedacht dass da ein Reboot
angeschmissen wird wenn man in 10min immer noch drin ist (was
manchmal nützlich wäre).

So etwa. Wenn ich aus der Ferne eingeloggt bin, dann sägen einige
Aktionen eventuell oder tatsächlich den Ast ab, auf dem ich sitze -
trifft auf jeden Fall für SSH zu.

Und die Übergabe von Befehlen per "at"-Job umgeht auf jeden Fall diese
Probleme, zudem wird die Konsole, auf der ich eingeloggt bin, nicht
weiter "belästigt"; ich brauche dann auch weder "&" noch "disown", um
sie (scheinbar) freizubekommen.

In umgekehrter Weise hat Frank Paulsen diesen Mechanismus mal
(prinzipiell) vorgestellt: zu Beginn der Basteleien definiert er einen
Job, der alle Änderungen zurücksetzt und (z.B.) in 1 Stunde gestartet
wird. Bei erfolgreicher Änderung sollte ich natürlich diesen Job löschen
...

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Nicht Relevant]

Post by Helmut Hullen

Post by Helmut Hullen
echo "reboot" | at now + 10 minutes
einzuplanen, und dann logge ich mich rechtzeitig vorher aus.

So etwa. Wenn ich aus der Ferne eingeloggt bin, dann sägen einige
Aktionen eventuell oder tatsächlich den Ast ab, auf dem ich sitze -
trifft auf jeden Fall für SSH zu.

Mit 'reboot' oder 'shutdown' habe ich mir noch in *keiner* ssh-Session
den eigenen Ast abgesägt.
Um nicht auf Timeouts warten zu müssen verwende ich trotzdem
typischerweise z. B. 'reboot;exit', aber keine Klimmzüge mit 'at' o. ä.

Post by Helmut Hullen
In umgekehrter Weise hat Frank Paulsen diesen Mechanismus mal
(prinzipiell) vorgestellt: zu Beginn der Basteleien definiert er einen
Job, der alle Änderungen zurücksetzt und (z.B.) in 1 Stunde gestartet
wird. Bei erfolgreicher Änderung sollte ich natürlich diesen Job
löschen ...

Meine Methode:
1. Öffnen einer zusätzlichen Session: date;sleep 300&&reboot
2. Änderungen durchführen, aber nur temporär
3. Stoppen der Kommandos in der Session unter Punkt 1 mit <Ctrl. C>.
Falls das nicht mehr gehen sollte kommt halt 'reboot' zum Zug.

[Harald Konz]

wird man den haengenden Pro- zess evt. nur durch einen reboot los ... Ganz

Du schreibst "evt." was mich einigermaßen neugierig macht.
Wenn also alle Mounts überprüft wurden und die Prozesstabelle nix mehr zum
killen hergibt was habe ich dann außer reboot evtl. noch für Optionen?.
Gibt es eine Möglichkeit noch was direkt an den Kernel zu bringen um einen
reboot zu vermeiden ?.
hk

[Hauke Laging]

Post by Harald Konz
Du schreibst "evt." was mich einigermaßen neugierig macht.
Wenn also alle Mounts überprüft wurden und die Prozesstabelle nix
mehr zum killen hergibt was habe ich dann außer reboot evtl. noch
für Optionen?. Gibt es eine Möglichkeit noch was direkt an den
Kernel zu bringen um einen reboot zu vermeiden ?.

Leider kann man die Treiber nicht resetten. Und auch wenn man ein
Modul vielleicht sogar entladen kann, während es "arbeitet" (also
hängt), wird das wohl den Prozess nicht aus seinem uninterruptible
sleep holen. Das ist halt eine peinliche Designpanne von Linux.


CU

Hauke

[Harald Konz]

Post by Hauke Laging
Leider kann man die Treiber nicht resetten. Und auch wenn man ein
Modul vielleicht sogar entladen kann, während es "arbeitet" (also
hängt), wird das wohl den Prozess nicht aus seinem uninterruptible
sleep holen. Das ist halt eine peinliche Designpanne von Linux.

Schade, ich dachte da wäre noch was mir Unbekanntes zu machen...
Was ist "uninterruptible sleep" genau, kann man vielleicht direkt in den
Speicher schreiben um diesen Zustand zu beenden?.
hk

[Harald Konz]

Hauke Laging wrote:

Vergiss die Frage, keine Chance solche Prozesse zu beenden...
Selbst wenn man den Speicher manipulieren würde müsste man ggf. eine
komplexe Struktur da reinschreiben was schon aus Platzgründen nicht geht.
Die Kiste würde unausweichlich instabil werden.
hk

[Bernd Hohmann]

Post by Harald Konz
Vergiss die Frage, keine Chance solche Prozesse zu beenden...
Selbst wenn man den Speicher manipulieren würde müsste man ggf. eine
komplexe Struktur da reinschreiben was schon aus Platzgründen nicht geht.

Es würde reichen einen INT 3 zu schreiben. Das geht natürlich nur, wenn
sich der Programmzähler noch irgendwie bewegt.

Bernd

[Harald Konz]

INT 3

Hab mir eben noch mal die Doku zu den Opcodes rein gezogen und ja... nee laß
ma. Das ist nicht mein Ding. Bis ich da durch bin gehe ich in Rente...
hk

[Hauke Laging]

Post by Harald Konz
Vergiss die Frage, keine Chance solche Prozesse zu beenden...
Selbst wenn man den Speicher manipulieren würde müsste man ggf.
eine komplexe Struktur da reinschreiben was schon aus Platzgründen
nicht geht.

Ich verstehe Dich nicht.

Ein Programm führt einen I/O-Call durch und gerät dadurch in Zustand
D. Der Kernelcode (oder die Hardware) verschluckt sich, deshalb wird
dieser Call nie beendet. Alles, was man zum Programm hin tun müsste,
ist, den Call mit einem Fehlercode zu beenden. Das sollte simpel
sein. Das Aufräumen im Kernel ist sicher schwieriger bis unmöglich
(da man nicht weiß, ob das Problem an der Hardware oder der Software
liegt). Denkbar wohl überhaupt nur bei Modulen. Aber wenn diese
Hardware dann bis zum Reboot nicht mehr benutzt wird (vielleicht
durch Kernelintervention gar nicht mehr benutzt werden könnte), wäre
schon einiges gewonnen.


CU

Hauke

[Michael Baeuerle]

Post by Hauke Laging
[...]
Das Aufräumen im Kernel ist sicher schwieriger bis unmöglich
(da man nicht weiß, ob das Problem an der Hardware oder der Software
liegt).

Schuld ist IMHO eindeutig der Treiber:
Der sollte bei einem Hardwareproblem nach einem Timeout eine
Fehlermeldung erzeugen und weitermachen (er koennte ja fuer mehrere
Geraete zustaendig sein und nur eins ist kaputt).


Micha

[Hauke Laging]

Post by Michael Baeuerle
Der sollte bei einem Hardwareproblem nach einem Timeout eine
Fehlermeldung erzeugen und weitermachen (er koennte ja fuer mehrere
Geraete zustaendig sein und nur eins ist kaputt).

Ja, klar. Nur sollte nach meinem Verständnis der Aufgaben eines
Betriebssystems der Kernel (auf Anforderung) diesen Call abbrechen,
wenn der Treiber verreckt ist. Der reißt ja in den betrachteten
Fällen eben nicht den ganzen Kernel mit in den Abgrund. Und das
Programm spricht AFAIK sowieso nicht direkt mit dem Kernel.


CU

Hauke

[Juergen Ilse]

Hallo,

Post by Hauke Laging

Post by Michael Baeuerle
Der sollte bei einem Hardwareproblem nach einem Timeout eine
Fehlermeldung erzeugen und weitermachen (er koennte ja fuer mehrere
Geraete zustaendig sein und nur eins ist kaputt).

Ja, klar. Nur sollte nach meinem Verständnis der Aufgaben eines
Betriebssystems der Kernel (auf Anforderung) diesen Call abbrechen,
wenn der Treiber verreckt ist.

Der Treiber ist Teil des Kernels und hat nicht "zu verrecken" und wenn
etwas nicht funktioniert, hat er die verwendeten Resourcen von sich aus
freizugeben ...

Post by Hauke Laging
Der reißt ja in den betrachteten Fällen eben nicht den ganzen Kernel
mit in den Abgrund.

Der Treiber ist kein "Programm, dass der Kernel zu unterbrechen hat"
sondern *Bestandteil" *des* *kernels*. Linux ist kein Mikrokernel-
System, bei dem die Treiber als seperate "Server-Prozesse" ausserhalb
des Kernels laufen.

Post by Hauke Laging
Und das Programm spricht AFAIK sowieso nicht direkt mit dem Kernel.

Es spricht schon direkt mit dem Kernel, aber nicht unbedingt direkt mit
dem Treiber, sondern mit der Schnittstelle des Kernels, die dieser fuer
die Kommunikation mit Programmen bereit stellt ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)