bug fix for Apache mod_fastcgi.c

Bob Ramstad (rramstad@nfic.com)
Thu, 20 Feb 1997 16:02:47 -0500 (EST)

Date: Thu, 20 Feb 1997 16:02:47 -0500 (EST)
Message-Id: <199702202102.QAA06232@bill-graham.nfic.com>
From: Bob Ramstad <rramstad@nfic.com>
To: fastcgi-developers@OpenMarket.com
Subject: bug fix for Apache mod_fastcgi.c

skip down to '********************' if you aren't interested in the
details of Apache.

howdy.  some may recall a thread a while back where people were having
problems with Apache (and perhaps other servers) spawning orphan
FastCGI processes.  from investigations here, it appears that the
problem is that Apache doesn't set up a signal handler until virtually
all initialization is completed.  the configuration file is parsed
fairly early -- therefore the FastCGI processes are started early too.
if Apache discovers a problem which doesn't allow it to successfully
start, it exits without sending any signals to the children.

it's easy to duplicate this.  simply start an Apache server which is
configured to do FastCGI *twice*.  the first time everything starts
fine.  the second time the Apache server dies -- can't listen to the
port -- but another set of FastCGI processes is left running.

this is actually a somewhat general problem.  exit is called many
times in the Apache code -- given the various states of initialization
which the system might be in, this could be bad, as there doesn't
appear to be much effort to clean up before exiting.  again,
generally, it would make sense for each module to have a cleanup
function and to have Apache call each of these if it needs to shut
down and that particular module has been initialized.

i'll freely and openly admit that i haven't looked at all of the
details, and i don't know what the best solution is, but we are
definitely going to suggest to the Apache folks that they use the
fuzzy eyeball on all the 'exit' calls and make sure that they are
clean.

********************

a simple fix to mod_fastcgi.c.  note that this is in the main loop of
the FastCGI process manager.  the flag caughtSigTerm is set whenever
it is detected that the parent process has gone away.

this works on Solaris and should work on virtually all Unixes.

diff -C 3 mod_fastcgi.c mod_fastcgi.c.dist 
*** mod_fastcgi.c       Thu Feb 20 13:12:46 1997
--- mod_fastcgi.c.dist  Wed Jan 15 12:41:04 1997
***************
*** 3135,3146 ****
          pid_t childPid;
          int waitStatus;
  
-       /* NFIC Testing */
-       if (getppid() == 1) {
-         caughtSigTerm = TRUE;
-       }
-       /* end NFIC */
- 
          /*
           * Examine each configured AppClass for a process that needs
           * starting.  Compute the earliest time when the start should
--- 3135,3140 ----

thanks to Rod and Matt for nailing this one down.

-- Bob

         _/      _/  _/_/_/_/  _/  _/_/_/_/                  
        _/_/    _/  _/        _/  _/                         
       _/  _/  _/  _/_/_/    _/  _/                          
      _/    _/_/  _/        _/  _/                           
     _/      _/  _/        _/  _/_/_/_/                      
                                                                        
New    Frontiers    Information    Corporation
222 3rd Street, Suite 0174, Cambridge MA 02142
phone: (617) 497-6811      fax: (617) 441-9265
  info@nfic.com         http://www.nfic.com/