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.