Mailing List Archive

> Why did IRIX have a problem with sys/time.h being in mod_cookies.c?
> Removing this breaks it for everything else I have encountered.
>
> FWIW, the offending #include line was for <sys/timeb.h>, which simply
> does not exist on a lot of systems. I gather that this #includes
> <sys/time.h>, which is all that's really needed after Cliff's other
> portability fixes, which is why the earlier-0.8.9 code worked.
> However, it seems pretty clear that just replacing it with
>
> #include <sys/time.h>
>
> would have been a better bet...
>
> Sigh...
>
> rst

Ahhhh. Ok. That makes sense.

FWIW - I have been running the 0.8.9 for most of today on my
main site. Seems to work fine with exception of the <sys/time.h>
problem in mod_cookies. What's the status on releasing this
version? I'd be happy to make the change to mod_cookies.c
and re-roll it before placing it on hyperreal if you would like.

Why did IRIX have a problem with sys/time.h being in mod_cookies.c?
Removing this breaks it for everything else I have encountered.

FWIW, the offending #include line was for <sys/timeb.h>, which simply
does not exist on a lot of systems. I gather that this #includes
<sys/time.h>, which is all that's really needed after Cliff's other
portability fixes, which is why the earlier-0.8.9 code worked.
However, it seems pretty clear that just replacing it with

#include <sys/time.h>

would have been a better bet...

Sigh...

rst

X-Uri: http://www.zyzzyva.com/
Date: Sat, 12 Aug 1995 20:00:23 -0500
From: Randy Terbush <randy@zyzzyva.com>

FWIW - I have been running the 0.8.9 for most of today on my
main site. Seems to work fine with exception of the <sys/time.h>
problem in mod_cookies. What's the status on releasing this
version? I'd be happy to make the change to mod_cookies.c
and re-roll it before placing it on hyperreal if you would like.

Depends what you mean by "release"... I'm happy to have this adopted
as a basis for further group work, but if a we could find a solution
to the repeated reports of flaky behavior on Solaris in the next few
days, it would probably be best to do that before the next *public*
release...

rst

+1 on finalising on 0.8.9.
Next public release being 0.8.10 perhaps?

With this as my cue, I've put the most recent 0.8.9 spin on hyperreal
(httpd/dist, *not* apache/dist) with the serious intention of closing
the books on it.

WRT public releases, as I've said, I think the main barrier there is
the flakiness on Solaris --- if someone in the group has duplicated it,
or has a reasonable line of attack, we should probably hold off until
that's finished. However, if not, it might be better to release 0.8.9,
with all the *other* bugfixes, and with a frank note saying that the
Solaroid members of the group can't duplicate the problem, appealing
for assistance from people that can. (NB, I said might --- I haven't
completely thought this through).

rst

>From: rst@ai.mit.edu (Robert S. Thau)
>Date: Sun, 13 Aug 95 13:55:53 EDT
>
> X-Uri: http://www.zyzzyva.com/
> Date: Sat, 12 Aug 1995 20:00:23 -0500
> From: Randy Terbush <randy@zyzzyva.com>
>
> FWIW - I have been running the 0.8.9 for most of today on my
> main site. Seems to work fine with exception of the <sys/time.h>
> problem in mod_cookies. What's the status on releasing this
> version? I'd be happy to make the change to mod_cookies.c
> and re-roll it before placing it on hyperreal if you would like.
>
>Depends what you mean by "release"... I'm happy to have this adopted
>as a basis for further group work, but if a we could find a solution
>to the repeated reports of flaky behavior on Solaris in the next few
>days, it would probably be best to do that before the next *public*
>release...

+1 on finalising on 0.8.9.
Next public release being 0.8.10 perhaps?

David.

On Tue, 15 Aug 1995, Robert S. Thau wrote:
> WRT public releases, as I've said, I think the main barrier there is
> the flakiness on Solaris --- if someone in the group has duplicated it,
> or has a reasonable line of attack, we should probably hold off until
> that's finished. However, if not, it might be better to release 0.8.9,
> with all the *other* bugfixes, and with a frank note saying that the
> Solaroid members of the group can't duplicate the problem, appealing
> for assistance from people that can. (NB, I said might --- I haven't
> completely thought this through).

The only flakiness I saw was that apparently solaris had problems with
nfs-mounted log files - did this get addressed somewhere along the way?
I know de-NFS'ing the logs made it stop hanging.

Brian

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

On Tue, 15 Aug 1995 21:27:04 PDT, Brian Behlendorf <brian@organic.com> wrote:

} The only flakiness I saw was that apparently solaris had problems with
} nfs-mounted log files - did this get addressed somewhere along the way?
} I know de-NFS'ing the logs made it stop hanging.

Actually I think any NFS mounted log files are a bad idea. There
is no atomic "append" in NFS, it is a seek and write. This is really
bad for logs :)

Cliff

In reply to David Robinson who said
>
> >The only flakiness I saw was that apparently solaris had problems with
> >nfs-mounted log files - did this get addressed somewhere along the way?
> >I know de-NFS'ing the logs made it stop hanging.
>
> Ahh well, I'm not surprised it doesn't work; no one mentioned log files
> over NFS before. I've justed checked; 0.8.8 hangs on a restart if error_log
> is NFS mounted.
>
> File locking on a file mounted over NFS is TERRIBLE BEHAVIOUR. Apart
> from the dire server performance this incurs, lock daemons are notoriously
> buggy.

Well, you're going to have a great deal of difficulty locking NFS files
on any of the free unices since they don't have lock daemons :-)

>
> Apache should NEVER be trying to lock a file that is mounted over NFS.
> And this is yet another reason why the scoreboard file should not be
> in the logs directory, performance will suffer again.
>

It's rather hard for apache to know whether a particular filesystem is
NFS mounted. It's quite possible to run apache on a diskless machine
(technically possible anyway).

This needs to be looked at another way. If possible change the way
apache works so that file locking is not necessary, or at least
minimised. For those cases where locking is absolutely essential then
document the fact that those file should not be on NFS mounts.

You can't do any more than this, you have to rely at some point on the
ability of the admin to set things up in a way that works :-) It's not
a very sound practive to have apache's log file on an NFS server anyway
since NFS write are slow and you have to write to the logs for every hit.

--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

Date: Wed, 16 Aug 95 10:06 BST
From: drtr@ast.cam.ac.uk (David Robinson)

Ahh well, I'm not surprised it doesn't work; no one mentioned log files
over NFS before. I've justed checked; 0.8.8 hangs on a restart if error_log
is NFS mounted.

File locking on a file mounted over NFS is TERRIBLE BEHAVIOUR. Apart
from the dire server performance this incurs, lock daemons are notoriously
buggy.

This can be solved for the moment by locking the scoreboard file
(which is, for now, guaranteed to be in /tmp); if we move the
scoreboard file elsewhere, then at that point we could open a file in
/tmp, and immediately unlink it; this would allow us still lock it,
with fcntl() at least (though not with flock()), while keeping files
from piling up in /tmp.

(And, clearing up another mystery, the reason this shows up only on
Solaris is that the accept()-locking is #ifdeffed out on other
systems).

Apache should NEVER be trying to lock a file that is mounted over NFS.
And this is yet another reason why the scoreboard file should not be
in the logs directory, performance will suffer again.

Actually, it's the first such reason I've heard --- it may not be a
bad one, though... FWIW, the scoreboard machinery doesn't require any
locking at all on the scoreboard file per se (it's arranged so that
there's only one process which should be writing a given byte in the
file at any given time), so it ought to *work* over NFS.

-1 on releasing 0.8.9 for 1 day to give me a chance to fix this.

Locking the scoreboard file instead of the error log should be
adequate for the moment... something like this: (warning: am testing
now...)

*** http_main.c~ Sat Aug 12 10:45:01 1995
--- http_main.c Wed Aug 16 09:26:23 1995
***************
*** 140,151 ****
#ifdef FCNTL_SERIALIZED_ACCEPT
struct flock lock_it = { F_WRLCK, 0, 0, 0 };
struct flock unlock_it = { F_UNLCK, 0, 0, 0 };

void accept_mutex_on()
{
int ret;

! while ((ret = fcntl(fileno(server_conf->error_log),F_SETLKW, &lock_it)) < 0
&& errno == EINTR)
continue;

--- 140,152 ----
#ifdef FCNTL_SERIALIZED_ACCEPT
struct flock lock_it = { F_WRLCK, 0, 0, 0 };
struct flock unlock_it = { F_UNLCK, 0, 0, 0 };
+ static int scoreboard_fd;

void accept_mutex_on()
{
int ret;

! while ((ret = fcntl(scoreboard_fd, F_SETLKW, &lock_it)) < 0
&& errno == EINTR)
continue;

***************
*** 158,164 ****

void accept_mutex_off()
{
! fcntl (fileno(server_conf->error_log), F_SETLKW, &unlock_it);
}
#else
/* Default --- no serialization. Other methods *could* go here,
--- 159,165 ----

void accept_mutex_off()
{
! fcntl (scoreboard_fd, F_SETLKW, &unlock_it);
}
#else
/* Default --- no serialization. Other methods *could* go here,

>Date: Tue, 15 Aug 1995 21:27:04 -0700 (PDT)
>From: Brian Behlendorf <brian@organic.com>
>
>On Tue, 15 Aug 1995, Robert S. Thau wrote:
>> WRT public releases, as I've said, I think the main barrier there is
>> the flakiness on Solaris --- if someone in the group has duplicated it,
>> or has a reasonable line of attack, we should probably hold off until
>> that's finished. However, if not, it might be better to release 0.8.9,
>> with all the *other* bugfixes, and with a frank note saying that the
>> Solaroid members of the group can't duplicate the problem, appealing
>> for assistance from people that can. (NB, I said might --- I haven't
>> completely thought this through).
>
>The only flakiness I saw was that apparently solaris had problems with
>nfs-mounted log files - did this get addressed somewhere along the way?
>I know de-NFS'ing the logs made it stop hanging.

Ahh well, I'm not surprised it doesn't work; no one mentioned log files
over NFS before. I've justed checked; 0.8.8 hangs on a restart if error_log
is NFS mounted.

File locking on a file mounted over NFS is TERRIBLE BEHAVIOUR. Apart
from the dire server performance this incurs, lock daemons are notoriously
buggy.

Apache should NEVER be trying to lock a file that is mounted over NFS.
And this is yet another reason why the scoreboard file should not be
in the logs directory, performance will suffer again.

-1 on releasing 0.8.9 for 1 day to give me a chance to fix this.

David.

> Apache should NEVER be trying to lock a file that is mounted over NFS.
> And this is yet another reason why the scoreboard file should not be
> in the logs directory, performance will suffer again.

Well, I guess we'll be having a:

ScoreBoard

directive in the conf files then.


> -1 on releasing 0.8.9 for 1 day to give me a chance to fix this.

I just checked and Brian's not put the latest version of 0.8.9 on /dist/
yet.

> David.
>