Re: Zombie fastCGI processes.

Mark Brown (mbrown@openmarket.com)
Thu, 12 Sep 1996 12:29:56 -0400

Message-Id: <199609121629.MAA12664@breckenridge.openmarket.com>
To: Michael Smith <mjs@cursci.co.uk>
Subject: Re: Zombie fastCGI processes. 
In-Reply-To: Your message of "Wed, 11 Sep 1996 11:48:54 BST."
             <32369916.60C19E10@cursci.co.uk> 
Date: Thu, 12 Sep 1996 12:29:56 -0400
From: Mark Brown <mbrown@openmarket.com>


Michael Smith reports:

    I have just noticed this problem with apache (1.1.1) / fastCGI
    (1.2/1.3) on solaris 2.5.

    It seems that when I kill/restart my server the fastCGI processes
    do not get killed.  This accumulates over time, so I found I had
    over 20 running around just now.

    Does anyone else see this?

In 1.2 there were bugs in this neck of the woods; I am not
surprised to hear that processes accumulated.  In 1.3
I've seen only two cases of this:

1) On some platforms (including Solaris) the app manager will lose
if you change the binary while the server is running.
So, e.g. if you upgraded from mod_fastcgi 1.2 to 1.3 by
replacing the binary, then stopping the server, then
starting the server, you'll get a bunch of parentless
(not technically zombie) FastCGI processes.

2) When you send SIGTERM to the Apache server, the Apache server sends
SIGTERM to the app manager and waits for it to die.  If it doesn't die
within 3 seconds Apache sends SIGKILL, which brings the app manager to
an immediate end.

If the app manager is paged out (pretty likely) and your system is
loaded then 3 seconds may not be enough to wake up the app manager and
have it kill off all the FastCGI processes.

It would be interesting for you to bump up the 3 second timeout and
see if that makes things work more reliably.  If not, perhaps there is
some new problem to be diagnosed.

Ultimately it might be necessary to implement some kludge like
a file containing the PIDs of the FastCGI processes.
I'd like to work the issue with the Apache folks before
resorting to such a kludge, since PIDs get recycled.

    --mark