Hallo, hab hier ein Problem. Ich wollte scannen, aber von gimp ist da noch xscanimage, zweimal, und blockiert den Scanner. Gimp hab ich vorher abgeschossen :(. Naja, aber jetzt kann ich die beiden Prozesse einfach nicht killen! xscanimage(10218) xscanimage(10408) Nichmal als root hat das folgende irgendeine Auswirkung! kill -s SIGKILL 10218 kill -s SIGTERM 10218 Auch über "KDE-Systemüberwachung" gehts nicht! Und deshalb neustarten... MfG Markus
Am Montag, 23. Juni 2003 18:48 schrieb Markus Hochmann:
Hallo,
hab hier ein Problem. Ich wollte scannen, aber von gimp ist da noch xscanimage, zweimal, und blockiert den Scanner. Gimp hab ich vorher abgeschossen :(. Naja, aber jetzt kann ich die beiden Prozesse einfach nicht killen! Achja, beide haben den Status "Festplatte inaktiv", obwohl ich alles Platten benutze :S xscanimage(10218) xscanimage(10408) Nichmal als root hat das folgende irgendeine Auswirkung! kill -s SIGKILL 10218 kill -s SIGTERM 10218
Auch über "KDE-Systemüberwachung" gehts nicht! Und deshalb neustarten...
MfG Markus
Hallo, On Mon, 23 Jun 2003, Markus Hochmann schrieb:
Am Montag, 23. Juni 2003 18:48 schrieb Markus Hochmann: Achja, beide haben den Status "Festplatte inaktiv", obwohl ich alles Platten benutze :S
Meinst du Status 'D'? Probiere mal, den scanner auszuschalten und die SCSI (und/oder USB) Module zu entladen. Evtl. klappt's. Je nach HW geht aber, wenn die sich erstmal verklemmt hat, nix anderes als neu booten. -dnh -- Um Rekursion zu verstehen, muss man erst Rekursion verstanden haben.
Am Montag, 23. Juni 2003 18:48 schrieb Markus Hochmann:
Hallo,
hab hier ein Problem. Ich wollte scannen, aber von gimp ist da noch xscanimage, zweimal, und blockiert den Scanner. Gimp hab ich vorher abgeschossen :(. Naja, aber jetzt kann ich die beiden Prozesse einfach nicht killen! xscanimage(10218) xscanimage(10408) Nichmal als root hat das folgende irgendeine Auswirkung! kill -s SIGKILL 10218 kill -s SIGTERM 10218
Auch über "KDE-Systemüberwachung" gehts nicht! Und deshalb neustarten...
MfG Markus
Probiere es mal mit kill -9 <JobID>. Gruß Marcus
Hallo, On Mon, 23 Jun 2003, Marcus Habermehl schrieb:
Am Montag, 23. Juni 2003 18:48 schrieb Markus Hochmann:
Nichmal als root hat das folgende irgendeine Auswirkung! kill -s SIGKILL 10218 kill -s SIGTERM 10218
Probiere es mal mit kill -9 <JobID>.
Das ist das gleiche wie 'kill -KILL <PID>' und 'kill -s SIGKILL <PID>' -dnh -- You come out of a woman and you spend the rest of your life trying to get back inside. -- sig stolen from James Cort
Markus Hochmann wrote:
Auch über "KDE-Systemüberwachung" gehts nicht! Und deshalb neustarten...
Jaa, das passiert ab und an. Bei "kill -9", bzw. "kill -s SIGKILL" sollte man sich deshalb sicher sein, das man das richtige tut. Manchmal reicht auch ignorieren, bzw. die Aufraeumarbeiten erledigen, die das kill -9 verhindert hat (lock-files, Sockets, etc.) Peter
Am Montag, 23. Juni 2003 19:20 schrieb Peter Wiersig:
Markus Hochmann wrote:
Auch über "KDE-Systemüberwachung" gehts nicht! Und deshalb neustarten...
Jaa, das passiert ab und an. Bei "kill -9", bzw. "kill -s SIGKILL" sollte man sich deshalb sicher sein, das man das richtige tut. Hab xkill genommen, für gimp...
Manchmal reicht auch ignorieren, bzw. die Aufraeumarbeiten erledigen, die das kill -9 verhindert hat (lock-files, Sockets, etc.) Hmm, der Prozess läuft ja noch, man kann ihn ja nicht killen!
Am Montag, 23. Juni 2003 18:55 schrieb Marcus Habermehl:
Probiere es mal mit kill -9 <JobID>. Hat auch keine Auswirkungen :(
MfG Markus
On Mon, Jun 23, 2003 at 07:32:07PM +0200, Markus Hochmann wrote:
Hmm, der Prozess läuft ja noch, man kann ihn ja nicht killen!
In Unix sollte ein "kill -9 <pid>" in jedem Fall den bezeichneten Prozeß killen, so man die entsprechenden Berechtigungen hat. Es gibt nur eine Situation, in der das nicht geht, und das ist, wenn der Prozeß gerade im Kernel in einem Gerätetreiber ist, und der Gerätetreiber eine Sektion betreten hat, die mit "uninterruptible sleep" markiert ist. Manche Gerätetreiber müssen dies machen, wenn sie auf bestimmte Interrupt-Serviceroutinen warten. Die Theorie ist, daß sie niemals lange in einer solchen Sektion sind, und daß daher der kill wirksam wird, sobald der Treiber die Sektion verläßt. Die Praxis ist, daß Geräte und Gerätetreiber fehlerhaft sind und daß in einer solchen Situation der Treiber auf eine Unterbrechung wartet, die nie kommen kann oder nie mehr kommen kann, weil er sie bereits verpaßt hat. In diesem Fall hängt der Prozeß dauerhaft in einem uninterruptible sleep rum. Das ist im Grunde genommen ein Fall für den Treiberprogrammierer und in jedem Fall ein Defekt. Wenn sich der Fehler sicher reproduzieren läßt, dann solltest Du gegen den Treiber einen Bugreport filen und die genauen Anweisungen zur Reproduktion des Fehlers darin nennen. Kristian
* Markus Hochmann schrieb am 23.Jun.2003:
hab hier ein Problem. Ich wollte scannen, aber von gimp ist da noch xscanimage, zweimal, und blockiert den Scanner. Gimp hab ich vorher abgeschossen :(. Naja, aber jetzt kann ich die beiden Prozesse einfach nicht killen! xscanimage(10218) xscanimage(10408) Nichmal als root hat das folgende irgendeine Auswirkung! kill -s SIGKILL 10218 kill -s SIGTERM 10218
Welchen Prozeßstatus hatte denn der Prozeß? R, S, D, Z oder T? Bei R, bzw. S und auch T müßte ein killen möglich sein. Bei D nicht. Ein Zombie, (Z) ist tot, er kann nicht mehr gekillt werden. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
On Mon, Jun 23, 2003 at 09:26:15PM +0200, Bernd Brodesser wrote:
Bei R, bzw. S und auch T müßte ein killen möglich sein. Bei D nicht. Ein Zombie, (Z) ist tot, er kann nicht mehr gekillt werden.
Ein Zombie ist ein Eintrag in der Prozeßliste, der bereits gelöscht ist und der nur noch einen Exitstatus enthält. Der Parentprozeß des Zombies läuft noch, und da er den (damals noch-nicht-)Zombie gestartet hat, kann er einen Exitstatus erwarten. Diesen müßte er mit wait() abholen. Ein Zombie entsteht, wenn ein Kindprozeß endet, der Elternprozeß sich aber nicht darum kümmert und insbesondere den Exitstatus mit wait nicht abholt. Der Zombie verschwindet, sobald der Elternprozeß wait() macht oder indem der Elternprozeß gekillt wird (dann wird die PID 1 als PPID eingesetzt, das ist init, und init macht ständig wait() und frühstückt den Zombie so ab). Dies alles ist Teil des fork()/exec()/wait()/exit()-Zyklus, aber das ist eine andere Geschichte, die ein anderes Mal erzählt werden soll. Kristian
participants (6)
-
B.Brodesser@t-online.de
-
David Haller
-
Kristian Koehntopp
-
Marcus Habermehl
-
Markus Hochmann
-
Peter Wiersig