[TransWarp] Pre-forking event-driven services

Phillip J. Eby pje at telecommunity.com
Fri Aug 15 09:54:23 EDT 2003


At 08:58 AM 8/15/03 -0400, Phillip J. Eby wrote:
>Meanwhile, if you configure so as to be able to shut down running 
>processes without mod_fastcgi starting them again, it will play a fun game 
>called, "start processes and then kill them before they do anything", 
>whenever processes are started just before its periodic "kill idle 
>processes" event.  (The slower the process start, the worse this hurts, 
>because the the window in which it can occur gets larger, and because more 
>work is wasted when it does happen.)

After a little investigation, I've realized that it doesn't matter how you 
configure mod_fastcgi: if processes exit on their own, for *any* reason 
except mod_fastcgi killing them, they will be marked for restart.  In other 
words, you *can't* configure mod_fastcgi such that you can shut down 
running processes.  Period.  :(

It looks as though we may want to define a signal used to tell the PEAK 
process manager to stop its children and then "play dead".  Then, assuming 
we configure mod_fastcgi to always have at most one process running, 
everything should work out as we'd like.  Although mod_fastcgi will 
probably kill our "frozen" process manager at its next idle-killing 
interval, it won't restart it if no requests are coming in.

Unfortunately, this still doesn't fix the "start-and-kill" problem.  More 
on this later.




More information about the PEAK mailing list