On 11/11/2013 10:50 AM, Stefan Fritsch wrote:
On Thu, 7 Nov 2013, Joe Orton wrote:
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.
I think LDAPLibraryDebug is one user of stderr going to the error log. As
the logging is done by the ldap library, there is really no way to change
it. But I guess it would be acceptable if that works only if logging to a
file (as long as logging to a file can be enabled even if the normal
logging goes somewhere else via an error log provider).
Hm, it does not work like that currently. You can have just one active
error log provider (so you log only to file or only using provider).
However, current situation is not a regression. Stderr output done by
LDAPLibraryDebug has been lost already in httpd-2.2 if the admin used
"ErrorLog syslog".
The solution could be forking another process which would read from
stderr and send it to error log provider, but I personally think it's
not worth doing it.
Another solution could be logging stderr to file and everything else
using error log provider, but this way looks little bit messy to me...
Regards,
Jan Kaluza
