process killen lukt niet??

[Verwijderd]

Ik had een hdparm ff gegeven om de performance te testen

root 2965 80.3 0.1 2376 1404 ? R 21:02 8:53 hdparm -tT /dev/h


das de ps aux uitdraai van het proces

leuk
kill 2965
dan maar webmin:

Command hdparm -tT /dev/hda1
Process ID 2965 Parent process init
Owner root CPU 79.0 %
Size 2376 kB Run time 00:11:46
Nice level -20 (High priority)-19-18-17-16-15-14-13-12-11-10-9-8-7-6-5-4-3-2-10 (Default)1234567891011121314151617181920 (Low priority)
Real group root Process group ID 2965


Group root TTY None

Maar mag ik die init killen? Ik meen van niet maar dat ben ik.....

[Wilke]

Als je root bent en kill -9 2965 intikt dan moet 'ie zeker weg zijn.

Okee, dat heb je dus al gedaan, zet dat er dan ook bij!

Dan hangt hdparm waarschijnlijk op een kernel-space request (lock die niet vrijgegeven wordt), da's naar...iemand die weet wat daar aan te doen is behalve rebooten?

[ Voor 55% gewijzigd door Wilke op 21-12-2002 21:32 ]

[Verwijderd]

k heb em maar een reboot gegeven met bibberende knieen

help me hopen

hijs thx god up...

maar wat te doen als er de volgende keer zoiets vastslaat?

[ Voor 38% gewijzigd door Verwijderd op 21-12-2002 21:33 ]

[Verwijderd]

Rebooten natuurlijk

Edit: Of hdparm niet testen natuurlijk

[ Voor 50% gewijzigd door Verwijderd op 21-12-2002 22:43 ]

[XTerm]

Een process dat met kill -p (KILL signal) niet gekilled kan worden bevindt zich in zombie state.
Wat is nu juist het probleem ? Als een process een child process forked, dan draait die child proces onafhangkelijk van de parent. De parent voert dan meestal een wait() of waitpid() system call uit om te wachten tot het process dood is.
Als echter de parent sterft voor het child kan exiten, of de parent gebruikt wait niet, dan wordt het child process een zombie proces. De kernel wijzigt de parent van het child dan naar init (dat bij uitzondering KILL negeert), en INIT cleaned zelf regelmatig de zombie processen.

Maar soms is zo'n zombie in een oneindige loop geraakt, of wacht het op iets dat nooit zal gebeuren. Dan heb je dus een echt, onkillbaar zombie process, dat je enkel kwijtraakt met een reboot. Die zombieprocessen kan je rustig negeren, tenzij ze natuurlijk exclusief een of ander device gelocked hebben. (Dit gebeurt bijna nooit).

[deadinspace]

XTerm schreef op 21 december 2002 @ 23:02:
Maar soms is zo'n zombie in een oneindige loop geraakt, of wacht het op iets dat nooit zal gebeuren. Dan heb je dus een echt, onkillbaar zombie process, dat je enkel kwijtraakt met een reboot. Die zombieprocessen kan je rustig negeren, tenzij ze natuurlijk exclusief een of ander device gelocked hebben. (Dit gebeurt bijna nooit).

Zombies kunnen niet in een oneindige loop raken; een zombie process is geen echt process meer, maar alleen een entry in de kernel process table. Een zombie bestaat alleen om bepaalde informatie (zoals de exit waarde van het process) op te slaan totdat de parent die informatie gelezen heeft en wait() doet.

Echt unkillable processes (met status D) kunnen ook ontstaan, maar dat zijn geen zombies. Als een process een systemcall doet, dan wordt de uitvoering van dat process stopgezet totdat die systemcall returnt. Signals voor dat process worden pas weer verwerkt op het moment dat de systemcall returnt.
Je voelt hem al aankomen: als zo'n systemcall niet returnt, dan is dat process niet te killen. Maar systemcalls die niet returnen zijn een serieus probleem dat niet zomaar voorkomt. Een voorbeeld zou zijn hardware die niet meer reageert: een harddisk begeeft het. Een process doet een read() op een file op die harddisk. De kernel gaat proberen die HD te benaderen, maar dat gaat grandioos fout omdat die HD bijvoorbeeld de IDE bus blokkeert en daar niet mee op houdt. De genoemde read() returnt niet en het process in kwestie is unkillable.

Dat laatste scenario krijg je doorgaans alleen door bugs in de kernel of brakke hardware (Met hardmounted NFS is het afaik ook mogelijk).

Verwijderd schreef op 21 december 2002 @ 21:20:
root 2965 80.3 0.1 2376 1404 ? R 21:02 8:53 hdparm -tT /dev/h

Dit process is dus niet unkillable, die 'R' betekent dat het process gewoon draait (waarbij het programma wel gecrasht kan zijn).

kill 2965

Heb je alleen "kill 2965" gedaan? Kill stuurt standaard een SIGTERM, wat zoveel betekent als "sluit aub nu af". Programma's zijn echter vrij om daarmee te doen wat ze willen, en als een programma hangt is het mogelijk dat dit signaal genegeerd wordt.
In dat geval moet je SIGKILL sturen, wat het process ongenadig beeindigd (SIGKILL kan niet genegeerd worden door normale processes).