Jim Jagielski wrote: > > Of course, releases can't be vetoed, but doing further research > indicates that Bill looks to be spot on with this issue...
The point is, this was released. Iteratively. I'm just not in a mood to keep +1'ing releases while the code remains in this broken state. It becomes more complex when you factor in the issue that on restart today we are losing stderr before we go through the process of the next restart loop. The recent patch sort-of-half fixed things, and they understood the issue, but at least on windows the stderr pipe was still inherited, so the logprocess still would not die until the last generation had been killed. It looks that leaving plog alone until we've run the new open log phase, then closing the older plog, combined with setting the old stderr pipe as not-inherited before we launch the new stderr pipe and replace stderr, we go a significant distance to fix this error. If my understanding on the [EMAIL PROTECTED] thread is correct, the issue further resolves itself with better win (os2? netware?) apr create_process changes. If not, it's another flaw in log.c to correct. My current stomach ache is mpm_winnt, which is also leaving inherited resources around long enough to be picked up by the logging processes. Once I'm done isolating those, it's a matter of ensuring what still goes on with launching cgi processes, and then the situation should be much better all the way around. Bill
