Subject: Re: runit not collecting zombies
Date: Wednesday 20th June 2007 16:57:36 UTC (over 10 years ago)
Hi! On Wed, Jun 20, 2007 at 04:23:25PM +0000, Gerrit Pape wrote: > # gcc test.c > # ./a.out This test exiting without leaving zombies and don't output anything on my home workstation (if you remember, I had to reboot workstation because of same issue few days ago). But for now this issue don't happens on workstation (yet, I think - uptime is just 2 days and it doesn't generate new processes as often as servers). Then I've executed this test on server, which already has this issue, but it don't have up to 8192 zombies for single user account and so I don't rebooted it yet. Before running test server has: # date; ps ax | grep Z | wc Wed Jun 20 16:42:18 GMT 2007 1259 7555 55496 test has printed several 'f', here is full output: $ ./a.out f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f $ and now there a lot of zombies: # date; ps ax | grep Z | wc Wed Jun 20 16:42:39 GMT 2007 17586 105517 790218 Several minutes later situation doesn't changed: # date; ps ax | grep Z | wc Wed Jun 20 16:49:04 GMT 2007 17587 105523 790263 > If not, can you provide this service daemon that produced these amount > of detached short-living processes? On my home workstation most of zombie processes was 'chpst' executed by dcron every 1 minute using lines like this one: */1 * * * * ( cd /var/www/soft.p/html && exec chpst -L .lib/var/.lock.service runsvdir .lib/service/ &>/dev/null ) & (I use runsvdir to run services in my web projects, and only way to guarantee these services will be started after reboot is cron configuration like this one - I don't like to use root access to start services for web projects.) Also I see a lot of zombie 'sshd' on my servers. So, I don't think this issue is in my perl scripts or other applications - it's somewhere in runit and/or kernel. > And I have another patch to try attached. Thanks, I'll try it. If I understand correctly, I should try this patch instead of previous, not together with previous..? -- WBR, Alex.