Re: [fwd] How to SysAdmin Apache FCGI ?

Tom Neff (tneff@ns1.bloomberg.com)
Mon, 17 Mar 1997 18:12:07 -0500

Message-Id: <3.0.32.19970317181043.00f5b4e0@mothra.bloomberg.com>
Date: Mon, 17 Mar 1997 18:12:07 -0500
To: udeupct@lexis-nexis.com
From: Tom Neff <tneff@ns1.bloomberg.com>
Subject: Re: [fwd] How to SysAdmin Apache FCGI ?

At 05:33 PM 3/17/97 -0500, Caleb Deupree wrote:
>>>>>> "Tom" == Tom Neff <tneff@ns1.bloomberg.com> writes:
>
>    Tom> IT IS NOT SAFE TO KILL AppClass PROCESSES OUTRIGHT.
>
>    Tom> The webserver can get out of sync (and leak resources) unless
>    Tom> the AppClass executable does an FCGI_Finish() and exits
>    Tom> gracefully.
>
>Just to make sure I understand, are you saying that restarting the
>server using the advertised method (e.g., kill -HUP `cat httpd.pid`)
>will cause the AppClass executables and the web server to get out of
>sync and leak resources?  I understand your point about restarting
>*individual instances* of AppClass executables with custom signals, but
>I also thought that the advertised method, which covers *all*
>subprocesses, was safe as well.

No, restarting the entire server (remember there are several possible
brands of server involved here) will do the trick -- at least when the
FastCGI apps are running locally! -- if you can afford that drastic action.
 Many of us cannot.

>The cgi-bin program that we have only sends HUP or TERM to the
>contents of the httpd.pid file, and provides the ability for one of a
>group of developers to re-initialize his/her particular AppClass
>(accepting the side effect of re-initializing all of them), in
>exchange for tracking down the owner of the processes.  This script is
>only used in a fairly dynamic development environment behind a
>firewall, for the convenience of a group of developers.  We would
>*never* consider or recommend putting such a script on a production
>server.

It would still be preferable for the FastCGI app skeleton you give your
developers to include a signal trap that performs a graceful exit.  The app
can write its own pidfile, and the 'kill -USR1 `cat pidfile`' command to
restart the app can be embodied in a simple CGI script, as another poster
here indicated.

There are too many legitimate reasons to require a quasi-permanent daemon
app like a FastCGI executable to do some extraordinary action, e.g.,
rereading a config file or reloading a database, for developers to rely on
crude measures like a total server restart.

If you have more than one process for an AppClass, let them write pidfiles
of the form pidfile.SampleAppClassName.23167,
pidfile.SampleAppClassName.23199, etc.  Then the cgi-bin can just 'kill
-USR1 `cat `pidfile.SampleAppClassName.*`' and have a nice day.

In fact, I wish that FastCGI encompassed a restart or signalling protocol
of its own.  It would be great to be able to say
	
	FCGIRestart /cgi-bin/restart_MyApp MyAppClass
	FCGISignal /cgi-bin/signal_MyApp MyAppClass 16

so that just requesting the special URL would cause the server to reap all
app processes of the named class... or send them the specified signal, to
be dealt with in a programmed way.

You could achieve this effect now by making the app itself recognize a
special URL... but only if you limit yourself to one process per class.
-- 
Tom Neff			Bloomberg, L.P.
<tneff@bloomberg.com>