William A. Rowe, Jr. wrote:

>I belive I've deciphered the "RotateLogs doesn't work for access logs
>on Windows" Apache 2.0.44 bug.  It's actually many bugs in conformance.
>
>First, rbb's reorg of the WinNT pipe logic (apr/file_io/win32/pipe.c rev 1.46) 
>causes server/log.c ap_open_piped_log() to create an async (nonblocking) 
>pipe.  This was very cool for internal pipes.  However, console apps that are
>unprepared for Overlapped IO (read: all of them) will die given an Overlapped 
>pipe handle.  Even APR doesn't assume (and shouldn't) that a pipe handle
>passed as stdin/stdout is an Async handle.  However, Async handles are
>the only way to do timeouts.
>
>Unix ap_file_pipe_create() always creates the pipes blocking.  In fixing the
>bug, by creating blocking handles (that can't be timed out) for Win32, I also
>discovered our nonblocking pipe logic was reversed for parent/child handles 
>of the child stdin process. I've just committed all those fixes, so this aspect 
>was patched as well.  If you look at the new apr_create_nt_pipe() API, it 
>might be worth renaming and exporting it as apr_file_pipe_create_ex().
>It's similar to apr_file_pipe_create() with the added blocking mode argument
>(APR_FULL_BLOCK, APR_FULL_NONBLOCK, APR_READ_BLOCK and
>APR_WRITE_BLOCK).  APR_PARENT/CHILD_BLOCK only makes sense
>to a function like apr_procattr_io_set.  In fact, for safety, that creation call
>should never create NONBLOCK child pipes, but that's another discussion.
>
>So part one was fixed, now we create the access log's rotatelogs process
>with a good stdin stream.  It survives to log an entry, but only until we call 
>apr_proc_other_child_check within the WinNT MPM's *maintenence* loop.
>
>It seems that apr_proc_other_child_check is only being used during teardown
>of the Unix children.  It also seems that the 'correct' flag passed to the maint
>function for your registered otherchild is APR_OC_REASON_RESTART when
>the process is still running.
>
>Now mod_log_config kills the child process on APR_OC_REASON_RESTART.
>Because Win32 doesn't call the function in maintenance like unix, but in a one 
>second health-check loop, we are blowing away our access logger process.
>
>Finally, it looks like apr_proc_other_child_read is the function we *really* wanted
>to use within the health check.  But it seems all of these apr_proc_other_child
>functions are really misdocumented within APR.  Would someone step up and
>spell out exactly what they are *supposed* to be doing within unix, and then we
>can discuss how to make them portable to Win32?  It seems we have too much
>bubblegum and bailing wire holding them together, and the fixes that I made to
>do *exactly* what Unix was doing has killed the WinNT mpm.
>
>Bill
>
What we want to do in the winnt MPM maintenance loop is peridically 
check to see of the process is still alive. It it is dead, it needs to 
be restarted (ie, reliable piped logs). apr_proc_other_child_read was 
used in the Unix side of the house to do a periodic read of the pipe to 
an OC.  On Unix, you can tell if the process on the other end is still 
alive by doing a read on the pipe. Cannot do that with pipes on Windows, 
so we use apr_proc_other_child_check instead.  I think we need one 
function (call it what you will but apr_proc_other_child_check seems 
okay to me) that checks the status of an OC and performs an action 
(specified on the call to apr_proc_other_child_check) based on the 
status.  I am guessing that the windows MPM is whacking the piped logger 
because ocr->proc->hproc is somehow hosed.

Bill