[vpsFree.cz: community-list] Zombie procesy

[Stanislav Petr]

Proces je jadrem oznacen jako zombie v pripade ze neni mozne predat
signaly - typicka situace je ze si rodic procesu neni schopen prebrat
exit kod (potomek prestal existovat ale jeho datove struktury existuji,
prave z duvodu nepredanyho rizeni rodici). Predek procesu se muze
zotavit, ukazka jak by to napr. mohlo fungovat (netestovano, na to jsem
ted linej, ale teoreticky je to dobre):

proces s PID 100 spusti potomka s PID 101
nasledne spustim napr:

kill -SIGSTOP 100 # ted bude proces 100 ve stavu T
kill -SIGTERM 101 # potomek se ukonci a chce predat navratovy kod rodici
kterej ale nedostava od planovace cas

a mame tu zombie s PID 101

a dokud neudelam:
kill -SIGCONT 100

tak bude proces 101 ve stavu Z a pritom se z nej nasledne bude schopen
probrat aniz bych mu vnucoval novej rodic.

Kdyz dojde k problemu s procesem ve stavu Z a je to potreba resit, tak
jeste existuje sice malo zname chovani Linux kernelu a to konkretne
signal SIGCHLD, ktery poslete rodici procesu ktery zustal jako zombie a
pokud vse funguje jak ma, mel by si rodic uklidit sve potomky.

PS: Pokud by rodic procesu prestal existovat (z jakehokoliv duvodu)
stane se v Linux rodicem procesu PID 1.

On 03.08.2015 22:11, Jakub Fišer wrote:
> Jak přesně se může zombík "zotavit" jinak, než že se mu vnutí novej rodič, kterej ho zabije? A to jde snad jen přes ptrace, což v kontejneru imho jít nemůže, protože nemáš jádro není tvoje.
> 
> 
> 
> August 3 2015 8:45 PM, "Stanislav Petr" <glux at glux.org> wrote:
>> Cau,
>>
>> po dnesnim vypadku node5 pozoruji v systemu problem se zombie procesy.
>> Stava se to jeste nekomu?
>>
>> ps ax | grep Z
>> 2567 ? Z 0:00 [/usr/libexec/mu] <defunct>
>> 2583 ? ZNs 0:00 [asterisk_sipcha] <defunct>
>> 2651 ? ZNs 0:00 [asterisk_channe] <defunct>
>> 2828 ? Z 0:00 [/usr/sbin/apach] <defunct>
>>
>> Zatim nevidim zadnou souvislost.
>>
>> Proces 2567 je perl script (perl 5.20.2, munin-update 2.0.25),
>> 2583 a 2651 je asterisk 13.4.0 a nakonec 2828 je apache-2.4.16
>>
>> Zajimave na tom je ze procesy po nejakem case se ze stavu Z zotavi.
>> Strace mi na to nefunguje:
>>
>> strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
>>
>> Pravdepodobne omezeni OpenVZ??? Ta nemoznost debugovani je docela
>> zvlastni a uvnitr OpenVZ kontejneru nevim co s tim, pristup k
>> /proc/sys/kernel/yama/ptrace_scope nemam, takze jediny vysvetleni ktery
>> mne napada je chyba/omezeni OpenVZ a nebo ze uz tenproces nekdo debuguje
>> (gdb/strace).
>>
>> --
>> Stanislav Petr
>>
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
> --
> Jakub Fišer
> IT | Security | Audit | Legal
> kuba at ufiseru.cz
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4224 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20150804/5c92ced6/attachment-0002.bin>