Re: mod_fastcgi

Jonathan Roy (roy@atlantic.net)
Thu, 11 Sep 1997 20:33:38 -0400

Message-Id: <3.0.2.32.19970911203338.0072d638@rio.atlantic.net>
Date: Thu, 11 Sep 1997 20:33:38 -0400
To: Gerardo Diaz Cuellar <gdiaz@blackbox.cegs.itesm.mx>
From: Jonathan Roy <roy@atlantic.net>
Subject: Re: mod_fastcgi
In-Reply-To: <Pine.NXT.3.91.970911180520.3726A-100000@blackbox>


  As far as I can tell, the patches are not in either devkit on the web
site. Using them with fastcgi programs written in C on Solaris (and maybe
IRIX), you should expect them to eventually lock up and need to restart
your web server.

  The main problem is that the first accept() the fastcgi program does is
missing the AcquireLock() ReleaseLock() code. Thus, if two cgis start near
each other, they might both call accept. Solaris doesn't let you call
accept multiple times on a socket, and you end up with an error state it
can't recover from.. so your fastcgi programs freeze up, and no more fcgi
until you restart the web server. This is fixed simply by adding locking
around the initial accept().

  The 2nd problem which was only found after the accept() was fixed, is
that sometimes a lot of processes might die that shoudln't. We have a
fastcgi that checks the mod time on it's config file, and if it changed it
will exit after the current connection. This way when we change a config,
all the fastcgis in that pool will cleanly restart on their own. The
problem was, with say 5 processes and updating the config file, 80+ new
fastcgis eventually started and died, with 5 eventually returning. That
error is in the way it checks if it is a FCGI. Basically, the check is
broken, and the result is that if two or more processes are trying to
determine if they are cgi or fastcgi, they will think they are cgi, and
exit after the first connection they handle.

  Anyways, those are the two problems as best as I can remember them. The
fixes are applied to FCGI.pm 0.31 so if you stick to perl on Solaris you
should be safe. The email archive on fastcgi.com appears to still be
non-functional. :/ Whenever I get more time, I'm going to set up MonARC or
a similar mailing list archiver and subscribe it to the list, so we can all
have a fastcgi archive. It's annoying to keep forwarding people old
patches. ;)

-Jonathan

At 06:13 PM 9/11/97 -0600, Gerardo Diaz Cuellar wrote:
>Ok i gotted it.
>
>So, the accept() fix migth not be still on the binaries of the 
>fcgi-devel-kit unless Roy tells us their are? Expecting response Roy.
>
>So whats the bug, that your pathces to mod_fcgi dealt with and now 
>prevents fcgis from hanging?
>
>regards
>
>-Gerardo
>
>On Thu, 11 Sep 1997, Stanley Gambarin wrote:
>
>> 
>> 
>> On Thu, 11 Sep 1997, Gerardo Diaz Cuellar wrote:
>> 
>> > Ok, so which are the newest version which includes all the patches and 
>> > has everything fix? ON FCGI? and on PERL5 sfio?
>> > 
>> 
>> 	I guess i should clarify the issue here... there are 3 separate
>> parts here.. 
>> 	1.  mod_fastcgi module that implements FastCGI protocol 
>> functionality for   the apache server by translating HTTP requests into
>> FastCGI requests and back
>> 	2.    FCGI developer kit - which implements the protocol for the
>> FastCGI application.. this covers overwriting stdio routines, FCGX_* 
>> functions, etc.
>> 	3.  Application libraries which allow implementation of the 
>> of the FastCGI applications in the language other than C.  They are build
>> on top of the FCGX_* routines.
>> 
>> 	I (personally) am dealing with (1) only and am not involved
>> in anything else.. (no time)
>> 	
>> 	(2) is still "maintined" by OpenMarket, but as far as I know,
>> the accept() fix was NOT put in the latest developer kit (i may be
>> mistaken, so Roy, if you can check it against whatever is on the 
>> website www.fastcgi.com... would appreacite it).
>> 
>> 	As for the (3), most of the libraries are still provides by
>> OpenMarket, with the following exceptions:
>> 	There are some changes for Java code to make it work with 1.2
>> release of JDK (or is it 1.1.3 ?)
>> 	Perl-FCGI module, which is maintained by Sven. Latest version
>> is .031 i think.
>> 
>> 	So, the whole purpose of this letter is ... next time when
>> you reporting problems/requesting enhancements/just baabbling, make
>> sure to report with one of the 3 items above you are 
>> referring to...
>> 
>> 					Stanley.
>> 
>> 
>> 
>
>

--
Jonathan Roy - roy@idle.com - Idle Communications, Inc.
Idle Communications, Inc. accepts contract programming
work for general purpose tools (or CGI) in Perl/C/C++.