[Linux]Process wil niet dood

[MadEgg]

Ik probeerde mijn floppydrive te unmounten(wordt via supermount gemount) om hem met e2fsck te lijf te kunnen gaan.

Het commando bleef echter hangen met een knipperende cursor en geen prompt. Na een paar minuten heb ik de xterm gesloten in de hoop dat dat hielp.

Daarna heb ik met een nieuwe xterm de floppy alsnog geunmount, deze keer wel met succes.

Er is echter nu alleen een umount proces achtergebleven met status R(Runnable), welke niet dood wil. Ik ben natuurlijk begonnen met -9 maar toen dat geen effect had heb ik een hele zooi andere willekeurige signalen erheen gestuurd, alles zonder succes.

Is er een manier om dit proces dood te krijgen zonder een reboot? Ik heb gezocht maar daar ging het altijd om het killen van Z of D processes, ben de R nog niet tegen gekomen.

Het process is irritant omdat ie alle CPU power opslokt...

Uit ps -aux:

code:

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root      8126 64.4  0.0  1336  404 ?        R    16:32  19:38 umount /mnt/floppy/

[ Voor 4% gewijzigd door MadEgg op 31-08-2003 17:08 ]

[Lancer]

Floppy d'r uit rukken? Supermount stoppen?

[MadEgg]

Supermount is geen los proces, zit in de kernel ingebakken. Kan ik dus ook niet stoppen. Ik kan nu inmiddels wel de floppy unmounten en mounten wat ik maar wil, maar dat heeft geen invloed op het al draaiende proces. Ook is ie helemaal niet met de floppy bezig, die eruit halen is dus geen enkel probleem en helpt ook niet.

[Lancer]

Is het proces geen zombie geworden?

[MadEgg]

Dan zou het proces status Z hebben, en zoals ik al zei heeft het proces status R van Runnable / On run queue.
Bovendien zijn Zombies niet bestaande processen die dus ook geen CPU power kunnen opslurpen en daardoor ook niet zo vervelend zijn als deze.

[blaataaps]

Lancer schreef op 31 augustus 2003 @ 17:20:
Is het proces geen zombie geworden?

MadEgg schreef op 31 augustus 2003 @ 17:03:


n met status R(Runnable), welke niet dood wil. Ik ben natuurlijk begonnen met -9 maar toen dat geen effect had heb ik een hele zooi andere willekeurige signalen erheen gestuurd, alles zonder succes.
[..]
Ik heb gezocht maar daar ging het altijd om het killen van Z of D processes, ben de R nog niet tegen gekomen.

blijkbaar niet : )
Ik denk dat als hij niet luistert naar kill -9 rebooten de enige optie is. Soms helpt het terugplaatsen van het schijfje of waar hij dan ook maar op wacht, maar dat is hier niet het geval, ik vrees dat het een reboot moet worden..

[Lancer]

Met strace kun je zien wat 'ie aan het doen is. Misschien wacht hij nog ergens op voordat de signalen geaccepteerd worden.

[Harrie]

Ik heb ooit eens een vergelijkbaar iets gehad. Ik heb maar gereboot, kwam er echt niet uit... Ben benieuwd of het bij jou wel gaat lukken, en vooral ook hoe

[MadEgg]

strace doet helemaal niets. Hij zegt dattie attached is aan het betreffende PID, en laat verder niets zien. Ik kan strace ook niet meer ctrl+c-en, killen vanuit andere terminal lukt nog wel(maar dan wel met KILL signal).

[MadEgg]

Na heel veel proberen, oa met strace en gdb, wat allemaal niets opleverde heb ik besloten maar te gaan rebooten.
Zelfs was niet DE oplossing, aangezien het rebooten niet automatisch ging. Bij het afsluiten werd geprobeerd om alle processen te killen en hier liep het spaak en kwam er geen reboot tot ik handmatig een harde reset heb uitgevoerd.

Is er niet een manier om ook kernel-processen hardhandig te killen net zoals gewone processen, en zo nee, waarom niet...

[wzzrd]

Normaal gesproken ís een sig9 volgens mij de manier van hardhandig killen. Wat zou kunnen, is dat je niet alle parents hebt gedood en dat er dus nog een [bash] proces bestaat dat eerst naar de eeuwige jachtvelden moet. Ik heb dit ook wel eens gehad (ook met mount trouwens) en er was idd. maar één oplossing, geloof ik. (Alle parent processen doodmaken hielp ook niet.) En dat was rebooten. Bij mij ging dat gelukkig wel 'zacht'.

[Verwijderd]

Als je de xterm niet had afgesloten had Alt-[SysRq]-k ook nog wel eens willen helpen...

[MadEgg]

de K van saK(volgens alt[sysrq]f... wat doet dat?

[DAzN]

Jammer dat je gereboot hebt. Misschien had je met een pstree -nlp nog kunnen zien of er inderdaad parent-processen de boel vasthielden.

[MadEgg]

Ik heb nog wel:

code:

pstree 8126

gedaan, waar 8126 de PID van dit umount proces was. Dit gaf als resultaat alleen het betreffende umount proces.

[Verwijderd]

Voordat je kan unmounten moet je inderdaad alle processen doden. Dat doe je met 'fuser'. Dus in dit geval waarschijnlijk fuser -km /mnt/floppy. Daarna kan je umount /mnt/floppy. Succes.

[MadEgg]

Zoals al vaker vermeldt was het floppy station niet in gebruik op het moment dat ik dat commando uitvoerde.
Toen ik gelijk daarna een nieuwe terminal opende en daar nogmaals hetzelfde commando gaf, ging het wel goed terwijl het andere proces nog steeds draaide.

Het is echter allang achter de rug, helaas door middel van een reboot.

[Verwijderd]

*sgop*

Hier met hetzelfde probleem, zij het nu met een harde schijf en op een remote bak, waardoor reboot niet echt mogelijk is. De load is getild tot > 2.00 en het betreft een backup partitie die elke nacht gemount en geumount wordt om te backupen.

Het evil proces:

code:

root      3681 97.0  0.0  1280  440 ?        RN   04:40 966:18 umount /dev/hdb7

Mijn pogingen totnogtoe:

fulgor:~# kill 3681
fulgor:~# kill 3681
fulgor:~# kill 3681
fulgor:~# kill -9 3681
fulgor:~# kill -9 3681
... (stuk of 20 keer)
fulgor:~# kill -9 3681

Nog wat info:

fulgor:~# fuser -vm /dev/hdb7
fulgor:~# pstree 3681
umount
fulgor:~#

voor degene die me kan helpen

[benoni]

Idee voor Linux kernel 2.8:

Systeempje maken dat je kunt doorstarten i.p.v. herstarten.
Dus: frisse kernel in het geheugen laden, alvast de daemon processen daaronder laten starten en dan snel het stokje doorgeven,

Kijken wie z'n server de 10 jaar uptime haalt... en dan voor de lol 10 nog jaar erbij! In combinatie met een hotswappable busstructuur (http://www.picmg.org/compactpci.stm) en SMP kun je zelfs je hele server verbouwen zonder een enkele herstart

Sst niks zeggen tegen Bill straks neemt ie hier ook vast een patent op

[Verwijderd]

Leuk idee, denk niet dat het enige zin heeft tho. Het linke aan restart is dat eoa filesystem corrupt is bijvoorbeeld, en dat je automatisch in maint mode komt en dat sshd dus nog niet opkomt. De BIOS ed werkt toch wel .

[Verwijderd]

[Defspace]

Je zegt dat je een hele zooi willekeurige signalen hebt gestuurd. Maar welke precies ?

kill -l geeft een lijst van signalen:

code:

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
 5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE
 9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2
13) SIGPIPE     14) SIGALRM     15) SIGTERM     17) SIGCHLD
18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN
22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO
30) SIGPWR      31) SIGSYS      32) SIGRTMIN    33) SIGRTMIN+1
34) SIGRTMIN+2  35) SIGRTMIN+3  36) SIGRTMIN+4  37) SIGRTMIN+5
38) SIGRTMIN+6  39) SIGRTMIN+7  40) SIGRTMIN+8  41) SIGRTMIN+9
42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13
46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14
50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10
54) SIGRTMAX-9  55) SIGRTMAX-8  56) SIGRTMAX-7  57) SIGRTMAX-6
58) SIGRTMAX-5  59) SIGRTMAX-4  60) SIGRTMAX-3  61) SIGRTMAX-2
62) SIGRTMAX-1  63) SIGRTMAX

Heb je bijvoorbeeld al kill -1 -9 PID geprobeerd ?

Stukje van een ander die ook met dit probleem zat:

> If a process doesn't respond to a SIGKILL (aka 'kill -9') it's most like-
> ly hanging in kernelspace (_the_ most common reason for this: a process
> is trying to access a resource (disk/net io) that's gone). As long as
> the process is in an uninteruptable part of the kernel code no signal
> will reach it. Reboot, i'm affraid :-/

[benoni]

Inderdaad, de herstart was waarschijnlijk noodzakelijk. Kan me herinneren dat ik ook al eens een heel rijtje kill-commando's op zombie-achtige processen heb zitten loslaten, kon ze pas met een herstart wegkrijgen.

BTW: sorry, ik had meer aan dit draadje willen breien maar werd achtervolgd door deadlines.