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

[Jeremy Chadwick]

Before we get into a discussion about this problem, I've two questions
and one comment:

Q1: What operating system are you seeing this behaviour on?  It matters
greatly.

Q2: Can you please provide full version numbers of Apache and not "2.0"
and "2.2"?

C1: You want sigprocmask(), not sigsetmask().  POSIX == good, please
adhere to it.  pthread_sigmask() also comes to mind.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

On Wed, May 21, 2008 at 01:31:08PM -0500, Davy Durham wrote:
> 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

> _______________________________________________
> suPHP mailing list
> suPHP at lists.marsching.biz
> http://lists.marsching.com/mailman/listinfo/suphp