On Sun, Nov 17, 2013 at 5:20 AM, Stefan Fritsch <s...@sfritsch.de> wrote:
> Am Dienstag, 12. November 2013, 13:33:23 schrieb Jan Kaluža: > > > 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". > > > > LDAPLibraryDebug is new in 2.4. > > > 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 think the StderrLog thing suggested by Jeff may be good idea, if is > not too complex to implement. I don't have any other ideas. > Here's a first pass that probably blows up across restart and probably needs to be refactored to reuse some existing apr_file_* calls: http://people.apache.org/~trawick/StderrLog-r1.txt It doesn't seem that complicated to me, but maybe I just want to address the stderr concern and forget about it ;) Synopsis: no provider, no StderrLog: stderr goes to main server error log no provider, "StderrLog none": stderr is routed to /dev/null no provider, "StderrLog logs/foo": stderr is written to that file provider, no StderrLog: stderr is routed to /dev/null provider, "StderrLog none": stderr is routed to /dev/null provider, "StderrLog logs/foo": stderr is written to that file (I think it would also be useful for a provider to have an optional callback to handle the disposition of stderr, as some providers may have an implementation which makes it natural to do so. But that's largely a separate issue from StderrLog.) -- Born in Roswell... married an alien... http://emptyhammock.com/