On 11/07/2013 07:07 PM, Jeff Trawick wrote:
On Thu, Nov 7, 2013 at 7:09 AM, Jan Kaluža <jkal...@redhat.com
<mailto:jkal...@redhat.com>> wrote:

    On 11/07/2013 11:11 AM, 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.

        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.


    Reading this I think I could commit my
    httpd-trunk-stderr-provider.__patch from older email in this thread.
    It does not fix stderr logging, but it fixes httpd-trunk problem
    where messages with NULL server_rec* are not logged.

    I'm attaching better version of that patch here (it fixes potential
    crash pointed out by Rüdiger when both logf and error_log_provider
    are NULL).

    If anyone is against it or has better idea how to fix logging of
    messages with NULL server_rec* when log providers are used, tell me.


Is the observation about NULL server_rec for modules that weren't
updated properly to pass ap_server_conf when no server_rec was
available, or for some window where ap_server_conf is NULL but
server_rec is needed?

I've originally observed that right in log.c in open_error_log(). ap_log_error calls there have NULL server_rec and in case something goes wrong during vhost logger initialization, the error messages about that are lost in case you use error log provider in ap_server_conf. That's what I'm trying to fix by that patch.

I haven't checked if there are other places where NULL server_rec is used, but I would say it's pretty common during httpd startup.

Jan Kaluza


        Regards, Joe


    Regards,
    Jan Kaluza




--
Born in Roswell... married an alien...
http://emptyhammock.com/

Reply via email to