Re: svn commit: r568326 - /httpd/httpd/trunk/server/log.c

On 08/23/2007 09:36 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> On 08/22/2007 01:28 AM, wroweapache.org wrote:
>>> Author: wrowe
>>> Date: Tue Aug 21 16:28:32 2007
>>> New Revision: 568326
>>>
>>> URL: 
http://svn.apache.org/viewvc?rev=568326&view=rev
>>> Log:
>>> Refactor r452431, because this should not be
fatal to starting
>>> the server if it's horribly broken.  The
alternative of returing
>>> 'rc' in this case would be to open /dev/null as
the error stream
>>> for this generation of the server; and even
more useless result.
>> Where do you see that /dev/null will be used as the
error stream in this case?
>> As far as I can see if log_child returns something
different than APR_SUCCESS
>> the whole open_logs hook fails and causes the
process to die.
> 
> The original patch was dying on win32 as-a-service,
because apr_file_open_stdout
> fails without a stdout handle.

Ok, just for a non windows guy to understand: If httpd runs
as a service we usually
have no stdout handle and thus apr_file_open_stdout fails,
correct?

> 
> Now, I fixed blessing win32 services with a stdout
handle /Device/null.
> That much is now healthy.

Fixed in r568446, correct?

> 
> As I got to thinking about this, when the situation is
this fatal, why kill
> an otherwise perfectly healthy server?  Worst case, we
have some piped loggers
> which hang around longer than desired.  It's a
situation which I wouldn't
> want to bring down a production server for.

Ok, so the situation, that you cannot get the stdout handle,
is very unlikely to
happen after you fixed the windows stdout problem, correct?
So if we deal with hanging piped loggers something else got
terribly wrong.

Regards

Rüdiger

Ruediger Pluem wrote:
> 
>> The original patch was dying on win32 as-a-service,
because apr_file_open_stdout
>> fails without a stdout handle.
> 
> Ok, just for a non windows guy to understand: If httpd
runs as a service we usually
> have no stdout handle and thus apr_file_open_stdout
fails, correct?

Yup.  (No stdin/stderr either although we worked around
those, already).

>> Now, I fixed blessing win32 services with a stdout
handle /Device/null.
>> That much is now healthy.
> 
> Fixed in r568446, correct?

Right.

>> As I got to thinking about this, when the situation
is this fatal, why kill
>> an otherwise perfectly healthy server?  Worst case,
we have some piped loggers
>> which hang around longer than desired.  It's a
situation which I wouldn't
>> want to bring down a production server for.
> 
> Ok, so the situation, that you cannot get the stdout
handle, is very unlikely to
> happen after you fixed the windows stdout problem,
correct?
> So if we deal with hanging piped loggers something else
got terribly wrong.

Yes, but it could be as simple as someone's module closing
stdout
inadvertently.  That shouldn't kill the server, would you
agree?

Bill