[suPHP] Apache-2.2 in mpm 'worker' mode

[Davy Durham]

Hi,
  I've found an issue when using mod_suphp with apache-2.2 when it's 
using it's newer "threaded" mode  (as I understand it, it's called "mpm 
worker"), as opposed to the "forked" mode (called "mpm prefork").

 If you're not familiar, when you have a threaded application, and you 
send it a signal, you're not quite sure which thread will receive the 
signal.  The thread that happens to be running at the time that it was 
raised will receive it.. so it's pretty much random.   However, while 
all threads in a process share the same signal handlers, they all have 
their own signal masks.  So if you want to ensure that a particular 
thread receive a signal, then you mask it out on all other threads.

Apache 2.2 (when using the *threaded* "worker" mpm) has (understandibly) 
masked a lot of signals out on all the worker threads which allows the 
controller thread to receive all these signals.  The problem is when a 
worker thread forks and executes something (such as suphp), the child 
process inherits the signal mask.  This mask continues to get inherited 
by further children unless one of them resets the mask to 0.

==

In my particular application, I'm using suphp to run a php script that 
eventually shells and does an arping.  The arping hangs indefinately 
because it inherited a signal mask that blocks some signal that arping 
is expect.  Granted this may be considered a bug in arping not setting 
the signal mask as it should, but the you can see the problem I hope.

And I was also seeing the same type problem when my application shells 
out to several other scripts within /etc/init.d/...

==

While trying to diagnose this problem I was having after upgrading from 
apache 2.0, I dug around and noticed that the signal mask of my php 
process was 0x0 when using apache 2.0, and 0xa207 when running on apache 
2.2. 

This prompted me to write a little C application that simply calls 
"sigsetmask(0);" and then execs the command I want to run.   The problem 
with arping and the rest was immediately fixed.

So only then did I realize I was using the threaded apache mode, and so 
I recompiled apache to use "mpm prefork" which is not threaded and 
everything worked as well as it did under apache 2.0.

I'm guessing somewhere in the 2.2 module developers guide, it specifies 
that modules that are going to fork and exec something will want to 
reset the signal mask to 0, but I have not looked. 

Anyway, it seems as though mod_suphp really needs to call 
"sigsetmask(0);" before executing the php interpreter so that the child 
process is not inheriting a signal mask that blocks bunch of signals.

For now, I'm just going to use the prefork mode, but other's will likely 
run into the same problem I was having before too long.  I'd probably 
switch back to the more efficient threaded mode if suphp were modified.

How does this sound?  I can provide the 2 line patch if you need me to.  
Let me know.


Thanks,
  Davy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.marsching.com/pipermail/suphp/attachments/20080521/1a161577/attachment.htm