On Wed, 6 Nov 2013 10:05:25 -0500 Jeff Trawick <traw...@gmail.com> wrote: > > What are the thoughts around handling stderr? > > In some cases it is just junk if not wrapped in a proper message > (i.e., there can be a requirement that error log be completely > parseable and/or a requirement that stderr has timestamps or other > info). But it seems to require a thread of execution to implement > that in order to avoid blocking the writer. (Recently I encountered > a situation where a third-party module called some library during > httpd init that wrote an initialization message directly to stderr, > and the message was stuck in the stdio buffer and forked into every > child process for later, multiple appearances :) ) > > I guess an error log provider could be given the opportunity to route > stderr wherever it wants, but that doesn't handle the existing > suckage of random, un-timestamped stuff in the log for normal > configurations. I guess you could have mod_stderr that may or may > not be enabled if you wanted stderr handled more cleanly (groan), > whether or not you had a provider for ap_log calls.
The windows nt event logging logic faced the same issue (and was the reason for the early _commit() call :), so stderr is shifted to a pipe to 'decorate' it into the event log queue, which would look very similar for timestamps/other annotations into a syslog provider.
