3 Aug
2015
3 Aug
'15
6:45 p.m.
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
3 Aug
3 Aug
8:11 p.m.
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(a)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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
--
Jakub Fišer
IT | Security | Audit | Legal
kuba(a)ufiseru.cz
4 Aug
4 Aug
12:01 a.m.
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(a)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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
--
Jakub Fišer
IT | Security | Audit | Legal
kuba(a)ufiseru.cz
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
8:53 a.m.
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(a)glux.org> wrote:
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
--
Jakub Fišer
IT | Security | Audit | Legal
kuba(a)ufiseru.cz
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
3393
days inactive
3394
days old
community-list@lists.vpsfree.cz
3 comments
3 participants
participants (3)
-
Jakub Fišer -
Jirka Bourek -
Stanislav Petr