On Tue, Nov 12, 2013 at 7:33 AM, Jan Kaluža <jkal...@redhat.com> wrote:
> 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... > I was thinking about adding "StderrLog <filename>|none" to be able to separate or discard the stuff that goes to stderr, whether or not a provider is being used. I think it would be useful in a more than one type of configuration. Provider in place? Acts like "StderrLog none" unless StderrLog is coded. No provider in place? stderr goes to the error log unless StderrLog is coded. A warning about StderrLog <filename> is that there is no built-in support for rotation (until/unless someone adds piped log support) and as such it is intended only to be active while collecting data for a problem, after which it should be disabled. > > Regards, > Jan Kaluza > > -- Born in Roswell... married an alien... http://emptyhammock.com/
