Hi Liste, wie kann ich denn bitte schoen Prozesse im "uninterruptible sleep" State killen (STAT D) ? OK, ok, der Name sagts ja eigentlich schon. Aber leider, leider ist hier ein Rechner, bei dem sich ein rpm -i aufgehaengt hat und als ich dann selber was installieren wollte musste ich feststellen, dass die RPM-DB natuerlich "gelockt" ist. BTW: Gibt es nicht vielleicht einen absoluten Killer-Befehl? Kill -9 ist oft, vielleicht sogar meistens erfolgreich, aber es gibt genuegend Situationen wie diese hier, wo er das nicht ist. Es laufen uebrigens auch keine Mutter- oder Tochterprozesse mehr, welche evt. blockieren koennten. :-( Danke Marcel -- _\|/_ My ~ is my castle... `(o-o)' /-----------------oOO-(_)-OOo---------------------------------------\ | Marcel Meyer | c/o Fachschaft Mathe/Physik/Info | | meyerm@fs.tum.de | Technische Universitaet Muenchen | | Tel.: +49.89.289-22997 | Arcisstrasse 19, D-80290 Muenchen | \-------------------------------------------------------------------/
* Marcel Meyer schrieb am 28.Sep.2001:
wie kann ich denn bitte schoen Prozesse im "uninterruptible sleep" State killen (STAT D) ? OK, ok, der Name sagts ja eigentlich schon. Aber leider, leider ist hier ein Rechner, bei dem sich ein rpm -i aufgehaengt hat und als ich dann selber was installieren wollte musste ich feststellen, dass die RPM-DB natuerlich "gelockt" ist.
BTW: Gibt es nicht vielleicht einen absoluten Killer-Befehl? Kill -9 ist oft, vielleicht sogar meistens erfolgreich, aber es gibt genuegend Situationen wie diese hier, wo er das nicht ist. Es laufen uebrigens auch keine Mutter- oder Tochterprozesse mehr, welche evt. blockieren koennten. :-(
Da kann es nichts geben, da der Kernel erst dann nach Signale schaut, nachdem er, der Kernel selber, was abgearbeitet hat. Wenn ein Prozeß den Status D hat, wird auf dem Kernel gewartet. Manchmal hilft warten. Allerdings muß man da schon richtig lange Warten. Stunden oder so. Bernd -- Bitte die Etikette beachten: http://home.t-online.de/~f.walle/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
From the keyboard of Marcel,
Hi Liste,
wie kann ich denn bitte schoen Prozesse im "uninterruptible sleep" State killen (STAT D) ? OK, ok, der Name sagts ja eigentlich schon. Aber leider, leider ist hier ein Rechner, bei dem sich ein rpm -i aufgehaengt hat und als ich dann selber was installieren wollte musste ich feststellen, dass die RPM-DB natuerlich "gelockt" ist.
BTW: Gibt es nicht vielleicht einen absoluten Killer-Befehl? Kill -9 ist oft, vielleicht sogar meistens erfolgreich, aber es gibt genuegend Situationen wie diese hier, wo er das nicht ist. Es laufen uebrigens auch keine Mutter- oder Tochterprozesse mehr, welche evt. blockieren koennten. :-(
Echt init läuft auf deiner Maschine nicht mehr? 'telinit u' schon versucht? Ansonsten in runlevel 1 wechseln und wieder zurück in den Ursprungslevel. bye Waldemar
Marcel Meyer wrote:
wie kann ich denn bitte schoen Prozesse im "uninterruptible sleep" State killen (STAT D) ?
Gar nicht :-(
OK, ok, der Name sagts ja eigentlich schon.
Eben.
Aber leider, leider ist hier ein Rechner, bei dem sich ein rpm -i aufgehaengt hat und als ich dann selber was installieren wollte musste ich feststellen, dass die RPM-DB natuerlich "gelockt" ist.
Seltsam, da hatte doch gerade neulich im Thread "Laufzeit eines Linux-Servers" jemand auch ausgerechnet mit rpm dieses Problem -- wird das 'ne Epidemie? ;-)
BTW: Gibt es nicht vielleicht einen absoluten Killer-Befehl? Kill -9 ist oft, vielleicht sogar meistens erfolgreich, aber es gibt genuegend Situationen wie diese hier, wo er das nicht ist.
Ein SIGKILL (das ist es, was von kill -9 verschickt wird) kann vom betroffenen Prozeß selbst in keinem Fall abgefangen werden. Daher gilt: Wenn sich ein Prozeß überhaupt killen läßt, dann geht's mit einem SIGKILL auf jeden Fall. (Trotzdem sollte man's erstmal sanfter versuchen, um dem Prozeß die Chance zu eventuell nötigen Aufräumarbeiten zu geben.) In dem Zustand "D" ist aber auch diese Möglichkeit nicht mehr gegeben, da der Prozeß sich an einer Stelle in einem Systemaufruf befindet, an der keinerlei Unterbrechung zulässig ist. Wenn ein Prozeß in diesem Zustand hängenbleibt, stellt sich aber ohnehin zunächst die Frage nach der Ursache. Wenn es keinen erkennbaren Grund (z.B. nicht mehr erreichbarer NFS-Server) gibt, könnte ein ernstes Problem (z.B. Hardware-Probleme, ein Kernel-Oops o.ä. -- ggf. mal nach entsprechenden Meldungen in /var/log/messages suchen) dahinterstecken, das ohnehin einen Reboot sinnvoll macht.
Es laufen uebrigens auch keine Mutter- oder Tochterprozesse mehr, welche evt. blockieren koennten.
Die wären für die Möglichkeit, einen Prozeß mit einem SIGKILL zu beenden, auch ohne Bedeutung. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org http://www.informatik.uni-bremen.de/~eilert/
participants (4)
-
B.Brodesser@t-online.de
-
Eilert Brinkmann
-
Marcel Meyer
-
Waldemar Brodkorb