On Thu, Oct 17, 2013 at 12:33:50PM +0000, Plüm, Rüdiger, Vodafone Group wrote: > Hmm. This points out another issue when using an error log provider for the > main server log: > We lose everything that the server or other programs like CGI-scripts write > to the stderr FD as it > is simply written to /dev/null. Don't we need to have a separate process in > this case that > like a piped logger reads from the reading end of the "stderr pipe" and > writes it > via ap_server_conf->errorlog_provider->writer to the log?
Jumping in here... Actually there should be few cases where modules write to stderr, no? I'm not sure we should even consider "writes to stderr get logged" a valid part of the module API. "If you're not using ap_log_*error, you're out of luck" is not totally unreasonable. mod_cgi does intercept stderr and logs it properly via ap_log_rerror, and mod_cgid does stderr logging differently anyway. One case which is common is the use of apr_procattr_child_errfn_set() to write exec() errors to stderr after forking a child. But perhaps we could and should provide a single common implementation of that which does something more useful. With "ErrorLog syslog" in current 2.x (and 1.3?), stderr is /dev/null already, so the status quo is that we lose stuff, though that is kind of ugly. Regards, Joe
