William A. Rowe, Jr. wrote:
I've noted that the recent changes leave us unable to regenerate a reliable piped log on win32 (perhaps we've been unable to for a very long time, I'm not spinning my wheels to audit it but moving forwards with its fix). I haven't checked if unix is affected, but it's trivial to check (kill -KILL the customlog child, and see if we successfully respawn it or fail).
Ok - here's what was up (or down, rather). It worked on unix with no issues because we shut down all the piped robust logging handles in the child; the child was never responsible for respawning them. It fails on win32 because the child creates its own set of logs, or logger processes, and it manages the restart if these die. (In fact in the parent we'll never look up to see if our child logger process actually died, because we aren't in an MPM work loop). Closing those handles in the windows child was fatal, an attempt to respawn would provide no reader handles to the child stdin. As a platform quirk, and with a platform specific patch, I've closed this bug on 2.0/2.2/trunk, but please feel free to slap my hand if it touches the non-win32 code path in any manner at all. Bill
