piped logger fixes and 2.0.49 and Windows

[Jeff Trawick <tr...@attglobal.net>]

The piped logger fixes themselves have been approved for backport.

     * piped log programs respawning after Apache is stopped. PR 24805
       bogus "piped log program '(null)' failed" messages during
       restart. PR 21648.  Two people have tested a similar log.c patch
       and the worker.c patch and given feedback in PR 24805.
         server/log.c r1.137
         PREREQ: ap_mpm_query(mpm-state) support in MPMs
         (If an MPM is used that doesn't support the query, a complaint
         will be written to the error log when a piped log program
         terminates, and it won't get restarted.)
         +1: trawick, jerenkrantz, nd

However, there is a regression on Win32, BeOS, and OS/2 until/unless those MPMs 
implement the mpm-state-query function.

     * PREREQ for another fix (stranded piped logger processes) -
       ap_mpm_query(AP_MPMQ_MPM_STATE)
       No updates are available at present for the BeOS or OS/2 MPMs,
       but that is not a showstopper for the other changes.
         server/mpm/winnt/mpm_winnt.c r1.303, r1.306
         server/mpm/winnt/mpm_winnt.h r1.44
         server/mpm/winnt/child.c r1.21
       +1: trawick, stoddard

Meanwhile, I've had a couple of people asking me for the code privately, so I'm 
anxious to get this in 2.0.49 and be done with it.

Is it reasonable to commit the piped logger stuff without the Win32/BeOS/OS/2 
support?  I think yes, even though that will result in crashing piped loggers 
not being restarted on those platforms until the platform maintainers get a 
chance to work through the MPM changes.  But if anyone is going to consider 
such a regression a SHOWSTOPPER later for getting 2.0.49 out the door, then 
this would be a bad move.

Thoughts?

Re: piped logger fixes and 2.0.49 and Windows

[Jeff Trawick <tr...@attglobal.net>]

Justin Erenkrantz wrote:
> --On Friday, February 27, 2004 6:01 AM -0500 Jeff Trawick 
> <tr...@attglobal.net> wrote:
> 
>> Is it reasonable to commit the piped logger stuff without the
>> Win32/BeOS/OS/2 support?  I think yes, even though that will result in
>> crashing piped loggers not being restarted on those platforms until the
>> platform maintainers get a chance to work through the MPM changes.  
>> But if
>> anyone is going to consider such a regression a SHOWSTOPPER later for
>> getting 2.0.49 out the door, then this would be a bad move.
>>
>> Thoughts?
> 
> 
> How hard would it be to guess what needs to happen in those MPMs?  I bet 
> OtherBill can quickly look at the Win32 patch and cast the 3rd +1 when 
> he gets to it.

ake stepped up to the Win32 task.

> But, for BeOS and OS/2, can we just put something in if 
> their maintainers aren't getting to it?  Or is it better to do nothing?  

If we do nothing, the error log should have

   "can't query MPM state; not restarting piped log program 'foo'"

which should be a big enough clue.

Re: piped logger fixes and 2.0.49 and Windows

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Friday, February 27, 2004 6:01 AM -0500 Jeff Trawick 
<tr...@attglobal.net> wrote:

> Is it reasonable to commit the piped logger stuff without the
> Win32/BeOS/OS/2 support?  I think yes, even though that will result in
> crashing piped loggers not being restarted on those platforms until the
> platform maintainers get a chance to work through the MPM changes.  But if
> anyone is going to consider such a regression a SHOWSTOPPER later for
> getting 2.0.49 out the door, then this would be a bad move.
>
> Thoughts?

How hard would it be to guess what needs to happen in those MPMs?  I bet 
OtherBill can quickly look at the Win32 patch and cast the 3rd +1 when he gets 
to it.  But, for BeOS and OS/2, can we just put something in if their 
maintainers aren't getting to it?  Or is it better to do nothing?  -- justin