Mailing List Archive

>
> I'm not going to put anything up immediately, but if we get sufficient
> +1s and no vetoes, I'd like to have something up, say, tomorrow evening.
>

> rst

Unless there's a problem with the patch David's looking into I
give my +1

If more time is needed for a better patch, I think it can wait until
the next revision... any fix is better than no fix as long as it
doesn't break something else.


rob

> It's been a week since 0.8.8 was publically released, and we've accumulated
> a whole bunch of bug fixes, none of which have made it to the users yet.
> We still aren't in shape for a "non-beta" release, and there are still
> bugs we need to decide how to fix *best* (including both Rob's ScriptAlias
> bug and the file-locking business), but all the same, I think it's time
> to start distributing the fixes we have. So, I'm calling for a vote on
> distribution of 0.8.9 plus my scoreboard-locking patch, while we decide
> what to do about the rest of this stuff. My vote on the issue is +1...
>
> I'm not going to put anything up immediately, but if we get sufficient
> +1s and no vetoes, I'd like to have something up, say, tomorrow evening.

I agree. Time to roll another.

+1

If I'm following things right, there are two competing patches for the
solaris hangs (rst vs. drtr?) I'd like to see some resolution on that
before releasing 0.8.9.

Please check out docs/known_bugsnew.html on the web site to see if there's
anything else we want to solve before 0.8.9....

Two other random comments:

1) in my opinion file locking on log files is just plain bad. I found
this out tonight while setting up some tricky internal web stuff - I want
to have two wholly separate daemons on two separate ports logging to the
same error and access log file, so I don't want to have one trying to
block the other by locking the log files.

2) We noticed that if DocumentRoot was a symlink to a directory somewhere
else, the server died on parsing the httpd.conf complaining that it wasn't
a directory. In the same vein, we had a need for a DocumentRoot that
might not exist at web server launch time, so we slightly modified
http_core.c to make the DocumentRoot-doesn't-exist condition a warning
instead of a fatal error. Do others think this is appropriate for apache
to do?

Brian

On Wed, 16 Aug 1995, Robert S. Thau wrote:
> It's been a week since 0.8.8 was publically released, and we've accumulated
> a whole bunch of bug fixes, none of which have made it to the users yet.
> We still aren't in shape for a "non-beta" release, and there are still
> bugs we need to decide how to fix *best* (including both Rob's ScriptAlias
> bug and the file-locking business), but all the same, I think it's time
> to start distributing the fixes we have. So, I'm calling for a vote on
> distribution of 0.8.9 plus my scoreboard-locking patch, while we decide
> what to do about the rest of this stuff. My vote on the issue is +1...
>
> I'm not going to put anything up immediately, but if we get sufficient
> +1s and no vetoes, I'd like to have something up, say, tomorrow evening.
>
> [. If new fixes do appear subsequently, well, the page does say that
> we may be changing things rapidly, so I think we have that option ;-)
> What I really want to avoid is the situation we had with the first
> beta, where we're perpetually holding off for a day or two at a time
> ... ]
>
> rst
>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Please check out docs/known_bugsnew.html on the web site to see if there's
anything else we want to solve before 0.8.9....

This cuts to the question I originally asked... we obviously haven't
caught up to all known bugs yet, but the question of a second beta now,
as I see it, is whether we want people to use, say, 0.8.9 + Dave's patch
(as I said, if it's been confirmed to work by a solaris victim, it's the
one to use --- NB both his and mine get out of the business of locking logs),
or whether we want them to continue using 0.8.8, which *also* has all those
bugs, and has, in addition, all the *other* bugs which we've already fixed.

rst

Brian:
> 1) in my opinion file locking on log files is just plain bad. I found
> this out tonight while setting up some tricky internal web stuff - I want
> to have two wholly separate daemons on two separate ports logging to the
> same error and access log file, so I don't want to have one trying to
> block the other by locking the log files.

Agreed, I've tried doing this lots of times, bringing a new copy of apache
up on 8888 alongside it's older sibling on 80. I don't want the servers to
interfere with each other, and I don't really care if they write to the same
log files for a short while.

http -nolocks

perhaps?

> 2) We noticed that if DocumentRoot was a symlink to a directory somewhere
> else, the server died on parsing the httpd.conf complaining that it wasn't
> a directory. In the same vein, we had a need for a DocumentRoot that
> might not exist at web server launch time, so we slightly modified
> http_core.c to make the DocumentRoot-doesn't-exist condition a warning
> instead of a fatal error. Do others think this is appropriate for apache
> to do?
>

If this is a feature that you find useful then certainly, Apache should be
able to do it. If its a general approach that's desirable:

http -warnings

Start the server but all sanity checks that would cause
failure just cause STDERR warnings. In all but the most
extreme cases (can't write scorebord file) proceed regardless.

It this useful? I mean you COULD add a million directives a la:

StartupIgnoreErrors

but is that what you *need*?

Basically if anyone's using funky hacks on standard apache code then I want to
get some too! ;)

Ay

Date: Thu, 17 Aug 95 13:36:17 BST
From: Andrew Wilson <andrew@www.elsevier.co.uk>
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

Brian:
> 1) in my opinion file locking on log files is just plain bad. I found
> this out tonight while setting up some tricky internal web stuff - I want
> to have two wholly separate daemons on two separate ports logging to the
> same error and access log file, so I don't want to have one trying to
> block the other by locking the log files.

Agreed, I've tried doing this lots of times, bringing a new copy of apache
up on 8888 alongside it's older sibling on 80. I don't want the servers to
interfere with each other, and I don't really care if they write to the same
log files for a short while.

http -nolocks

perhaps?

Ummm... the locks we're talking about are *not* meant to keep multiple
processes from writing to the logs simultaneously. So why lock them
at all?

Well, some systems do require mutual exculsion around the accept() in
standalone_main(); prior to 0.8.10 (hope, hope), that was done by
putting an advisory write lock on the error log, on the theory that
that was a file which all of the server processes would have open.
This was never intended to keep multiple servers from writing to the
log file itself at the same time (yet another good reason to put the
lock on something else; with drtr's code it's an empty file which
exists for the sole purpose of getting locked).

rst