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
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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-- Jakub Fišer IT | Security | Audit | Legal kuba@ufiseru.cz
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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-- Jakub Fišer IT | Security | Audit | Legal kuba@ufiseru.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ve zkratce - zombie proces se může zotavit tak, že jeho rodič vezme na vědomí, že se potomek ukončil. Nestane se to buď v případě, že se rodič nějak zasekl, nebo že je v něm chyba a na ukončení potomků vůbec nereaguje.
Stanislav Petr wrote:
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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-- Jakub Fišer IT | Security | Audit | Legal kuba@ufiseru.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
Jakub Fišer -
Jirka Bourek -
Stanislav Petr