zombie named

[Verwijderd]

ik heb een probleem, en jullie weten vast hoe ik dat kan oplossen?
ik heb een defunct named draaien, die wil ik dus killen, maar dat wil niet lukken
heb kill -9 <pid> en killall named enzo geprobeert, maar hij blijft gewoon draaien.
met een ps -eax krijg ik:
5735 pts/2 Z 0:00 [named <defunct>]

Iemand enig idee?

[ACM]

Lijkt me meer een NOS probleempje

Is ie na een tijdje, nog steeds aanwezig?

[Verwijderd]

Doe eens:

code:

ps -eo "ppid pid args"

Dit print onder het kopje ppid de parent-proces id.
Je kan een zombie namelijk niet zelf aan roepen, je moet bij de parent zijn.
Als je die afsluit dan zal ook de zombie foetsie zijn.

Als de ppid van de zombie overigens 1 is, dan heb je een probleem en kan je hem niet killen.

[Jordi]

In dat geval wil het nog wel es helpen om ff naar een ander runlevel (nee niet 6) te gaan en evt. weer terug.

[Verwijderd]

Op dinsdag 26 juni 2001 23:33 schreef Jotti het volgende:
In dat geval wil het nog wel es helpen om ff naar een ander runlevel (nee niet 6) te gaan en evt. weer terug.

Is dat zo? /me heeft wat bijgeleerd dan

Alleen jammer dat ik bijna nooit zombies heb om dit uit te proberen

[Verwijderd]

ps -eo pid,wchan

dat zegt meer hier met die zombie!!!!!

[deadinspace]

Mjah, khad ooit eens een zombie cardmgr... init 3; init 2 mocht niet baten... init 1; init 2 overleefde mijn computer niet, dat ging fout tijdens de init 2...

Maar init 3; init 2 (afhankelijk van wat je huidige runlevel is btw) zal je meestal niet helpen helaas. init 1; init 2 is een stuk rigoreuzer, en helpt vaak wel, maar dit heeft als 'bijwerking' dat al je programma's afgesloten worden.

[Jordi]

Remote 'init 1' wil je niet doen

[deadinspace]

Haha... nee, zo'n fout maak ik niet meer

* deadinspace heeft al eens remote ifconfig eth0 down gedaan, en ook al eens remote killall sshd

Maargoed, daar leer je van

[Verwijderd]

Op woensdag 27 juni 2001 01:59 schreef deadinspace het volgende:
Haha... nee, zo'n fout maak ik niet meer

* deadinspace heeft al eens remote ifconfig eth0 down gedaan, en ook al eens remote killall sshd

Maargoed, daar leer je van

Ai, ai, ai, die laatste komt nelske ook bekend voor

[Verwijderd]

ik ook... ik had een 55 dagen uptime... killall sshd..... bye bye uptime

[RvdH]

Waarom zou je het willen killen? Een zombie is niks meer dan een foutieve entrie in de processtabel, hij draait niet echt. Dus kost het geen performance ofzo. Dus zou ik er gewoon niets aan doen.

[Verwijderd]

Niks aan doen. Het enige dat bezet is is het pid. Verder worden er geen resources gebruikt. Je hebt gewoon een illegale huurder.
Bij een reboot zal het ding verdwenen zijn...

[imdos]

Op woensdag 27 juni 2001 04:15 schreef niksie het volgende:
ik ook... ik had een 55 dagen uptime... killall sshd..... bye bye uptime

Dat deed ik ook eens toen ik me sshd ging updaten. Gelukkig dat ik voor de zekerheid maar wel even telnet aangezet had, want je weet maar nooit in dat soort situaties

[ThE_ED]

Ik kan het woord 'zombie' niet meer zien sinds een hele tijd geleden ineens elk proces op m'n bak zombie ging... (Tsss. zelfs shutdown werd zombie...)

[The Jester]

Op woensdag 27 juni 2001 09:00 schreef Circe het volgende:
Bij een reboot zal het ding verdwenen zijn...

Niet dus! Of beter: niet per definitie.
Een zombaie kan héél hardnekkig zijn

[deadinspace]

Op woensdag 27 juni 2001 09:00 schreef Circe het volgende:
Niks aan doen. Het enige dat bezet is is het pid. Verder worden er geen resources gebruikt. Je hebt gewoon een illegale huurder.
Bij een reboot zal het ding verdwenen zijn...

Dat klopt dus niet: een zombie kan heel goed nog resources in gebruik hebben.
Ik heb eens een userspace driver voor de parallelle poort voor 2.4 geschreven, en als je dan /dev/parport0 opende, claimde en dan je process forkte, gingen beide processes zombie, en was /dev/parport0 bezet en niet meer vrij te krijgen.

Op woensdag 27 juni 2001 04:15 schreef niksie het volgende:
ik ook... ik had een 55 dagen uptime... killall sshd..... bye bye uptime

Erm? wrom zou je dat uptime kosten?
Gewoon als root inloggen op de console en sshd restarten, klaar ben je.

En dat kan niet remote nee, maar rebooten kan ook niet remote als je sshd niet meer draait...

Op woensdag 27 juni 2001 13:17 schreef The_Jester het volgende:

[Op woensdag 27 juni 2001 09:00 schreef Circe het volgende:
Bij een reboot zal het ding verdwenen zijn...]

Niet dus! Of beter: niet per definitie.
Een zombaie kan héél hardnekkig zijn

Erm... na een reboot is een zombie echt wel weg hoor.
Alleen als tijdens het booten iets gestart wordt wat op dat moment weer zombie gaat, dan heb je na de reboot ook een zombie ja, maar dat is dus een nieuwe, niet diezelfde.

Als je reboot, begin je helemaal met schone lei, dus kernel in het geheugen, init starten, en die init heeft dan geen childs, dus ook geen zombies. Wat later tijdens het bootprocess krijgt init pas childs, en als daar een prog bij zit dat zombie gaat, is dat dus niet dezelfde als diegene die je had voor de reboot.

[Verwijderd]

Op woensdag 27 juni 2001 17:40 schreef deadinspace het volgende:

[..]

Dat klopt dus niet: een zombie kan heel goed nog resources in gebruik hebben.
Ik heb eens een userspace driver voor de parallelle poort voor 2.4 geschreven, en als je dan /dev/parport0 opende, claimde en dan je process forkte, gingen beide processes zombie, en was /dev/parport0 bezet en niet meer vrij te krijgen.

Dat is toch wel heel erg vreemd moet ik zeggen. Bij mijn weten is een zombie (of defunct) proces toch echt een proces dat afgesloten is, waarvan de parent nog niet z'n exit status gekregen heeft of een proces dat afgesloten wordt, nadat de parent is afgesloten (hij wordt door init inherited). Hij verbruikt geen systeem-recourses (CPU, geheugen etc) alleen een ProcessID!!

Wat jij dus had, zal denk ik niet een defunct proces gewesst zijn, simpelweg omdat dat niet kan!

Op woensdag 27 juni 2001 13:17 schreef The_Jester het volgende:

Niet dus! Of beter: niet per definitie.
Een zombaie kan héél hardnekkig zijn

Niet Das best knap!
Na een reboot is hij echt wel weg hoor

[deadinspace]

Op woensdag 27 juni 2001 18:54 schreef nelske het volgende:

[..]

Dat is toch wel heel erg vreemd moet ik zeggen. Bij mijn weten is een zombie (of defunct) proces toch echt een proces dat afgesloten is, waarvan de parent nog niet z'n exit status gekregen heeft of een proces dat afgesloten wordt, nadat de parent is afgesloten (hij wordt door init inherited). Hij verbruikt geen systeem-recourses (CPU, geheugen etc) alleen een ProcessID!!

Wat jij dus had, zal denk ik niet een defunct proces gewesst zijn, simpelweg omdat dat niet kan!

Dat hangt van de definitie van zombie af dan.
Bij dat parport voorbeeld van mij gebeurde waarschijnlijk het volgende:

-prog opent /dev/parport0
-prog claimnt /dev/parport0
-prog forked
-parport kan slechts door 1 process geclaimed zijn, maar is nu door 2 pids geclaimed... kernel vindt dit niet lief (is hws bug in kerneldriver overigens)
-zowel parent als child gaat in modusje D (uninterruptible sleep)

In deze situatie zijn beide processes nog niet ge-exit, en hebben daarom dus nog wel resources in gebruik.

Dit valt inderdaad niet in de klassieke definitie van een zombie process.
Maar hoe noem je die processes van mij dan?

[Verwijderd]

deadinspace: Hoe noem je die processes van mij dan?

Wat er gebeurt is een deadlock (en evt starvation).

[Verwijderd]

Gewoon een Uninterrubtible Sleeping Process.
Dit verklaart jouw probleem wel heel wat meer.
Een Uninterruptible Sleeping Process heeft meestal met IO te maken

[Verwijderd]

Op woensdag 27 juni 2001 19:21 schreef nelske het volgende:
Gewoon een Uninterrubtible Sleeping Process.
Dit verklaart jouw probleem wel heel wat meer.
Een Uninterruptible Sleeping Process heeft meestal met IO te maken

Je kan dus zien wat er aan de hand is door:

ps -eo pid,wchan

te doen

[Verwijderd]

JA, maar schiet je daar wat mee op, op zo'n moment?

[deadinspace]

Op woensdag 27 juni 2001 19:28 schreef nelske het volgende:
JA, maar schiet je daar wat mee op, op zo'n moment?

Neuh... als mijn prog dit deed, ging het fout -> bug in kernel-handling paralelle poort.
Verder... tsja, rebooten he