Re: error log providers, multiple vhosts, mod_syslog

[Jeff Trawick <tr...@gmail.com>]

On Tue, Oct 29, 2013 at 7:04 AM, Jeff Trawick <tr...@gmail.com> wrote:

> On Tue, Oct 29, 2013 at 5:30 AM, Jan Kaluža <jk...@redhat.com> wrote:
>
>> On 10/25/2013 03:37 PM, Jeff Trawick wrote:
>>
>>> I'm hoping to get back to this discussion "soon."  I also have a 2.4.x
>>> patch I've played with that is roughly in sync with trunk (though syslog
>>> logging support isn't a provider in the 2.4.x version).
>>>
>>
>> Does your patch fix stderr logging? I wanted to write proof of concept
>> logger as described by Rüdiger below, but I didn't manage to find a time
>> for it recently :(. If you have working solution for that, I wouldn't waste
>> my time :).
>>
>>
> No, I just have a backport to 2.4.x with accommodation for syslog.
>

What are the thoughts around handling stderr?

In some cases it is just junk if not wrapped in a proper message (i.e.,
there can be a requirement that error log be completely parseable and/or a
requirement that stderr has timestamps or other info).  But it seems to
require a thread of execution to implement that in order to avoid blocking
the writer.  (Recently I encountered a situation where a third-party module
called some library during httpd init that wrote an initialization message
directly to stderr, and the message was stuck in the stdio buffer and
forked into every child process for later, multiple appearances :) )

I guess an error log provider could be given the opportunity to route
stderr wherever it wants, but that doesn't handle the existing suckage of
random, un-timestamped stuff in the log for normal configurations.  I guess
you could have mod_stderr that may or may not be enabled if you wanted
stderr handled more cleanly (groan), whether or not you had a provider for
ap_log calls.



>
>
>
>
>> Thanks,
>> Jan Kaluza
>>
>>
>>> On Thu, Oct 17, 2013 at 8:33 AM, Plüm, Rüdiger, Vodafone Group
>>> <ruediger.pluem@vodafone.com <ma...@vodafone.com>>
>>> wrote:
>>>
>>>
>>>
>>>      > -----Original Message-----
>>>      > From: Jan Kaluža
>>>      > Sent: Donnerstag, 17. Oktober 2013 13:21
>>>      > To: dev@httpd.apache.org <ma...@httpd.apache.org>
>>>      > Subject: Re: error log providers, multiple vhosts, mod_syslog
>>>      >
>>>      > There's another problem with log providers and vhosts and I think
>>>     I have
>>>      > no idea how to fix it without doing dirty hacks...
>>>      >
>>>      > The problem is with ap_open_logs function, which does following:
>>>      >
>>>      > 1. Main server log is opened (open_error_log()). If this log uses
>>>     error
>>>      > log provider, s_main->error_log is set to NULL.
>>>      >
>>>      > 2. When there is no s_main->error_log, stderr is redirected to
>>>     /dev/null.
>>>
>>>     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?
>>>
>>>      >
>>>      > 3. Error logs for vhosts are opened (another open_error_log()).
>>>     If there
>>>      > is some problem when opening these logs, any ap_log_error() call
>>>     is sent
>>>      > to /dev/null.
>>>
>>>     Wouldn't it try to call s->errorlog_provider->writer in line 1196
>>>     and Segfault if s->errorlog_provider
>>>     is NULL because of some bad "classic" configuration that simply
>>> failed?
>>>
>>>     Regards
>>>
>>>     Rüdiger
>>>
>>>
>>>
>>>
>>> --
>>> Born in Roswell... married an alien...
>>> http://emptyhammock.com/
>>>
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



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

Re: error log providers, multiple vhosts, mod_syslog

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Wed, 6 Nov 2013 10:05:25 -0500
Jeff Trawick <tr...@gmail.com> wrote:
> 
> What are the thoughts around handling stderr?
> 
> In some cases it is just junk if not wrapped in a proper message
> (i.e., there can be a requirement that error log be completely
> parseable and/or a requirement that stderr has timestamps or other
> info).  But it seems to require a thread of execution to implement
> that in order to avoid blocking the writer.  (Recently I encountered
> a situation where a third-party module called some library during
> httpd init that wrote an initialization message directly to stderr,
> and the message was stuck in the stdio buffer and forked into every
> child process for later, multiple appearances :) )
> 
> I guess an error log provider could be given the opportunity to route
> stderr wherever it wants, but that doesn't handle the existing
> suckage of random, un-timestamped stuff in the log for normal
> configurations.  I guess you could have mod_stderr that may or may
> not be enabled if you wanted stderr handled more cleanly (groan),
> whether or not you had a provider for ap_log calls.

The windows nt event logging logic faced the same issue (and was the
reason for the early _commit() call :), so stderr is shifted to a pipe
to 'decorate' it into the event log queue, which would look very similar
for timestamps/other annotations into a syslog provider.