httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: fcntl() errors on Solaris
Date Wed, 13 Aug 1997 02:54:05 GMT

One portion of the LockFile collaboration that we put together was 
to locate the lockfile in the same directory with the PID file as a 
default. We at least know that directory exists. Anything wrong 
with that assumption?

> On Tue, 12 Aug 1997, Alexei Kosut wrote:
> > On Tue, 12 Aug 1997, Marc Slemko wrote:
> > 
> > [...]
> > 
> > > NFS locking isn't, which is probably the biggest reason for your troubles.
> > 
> > Yeah. I suspected that, but I wanted to email and make sure. Switching
> > LockFile to a local file seems to work.
> I'm still contemplating if it is wise to move the default lockfile to
> /tmp.  Shoot, I wanted to try to resolve the issue of lockfile placement
> before the next 1.2 release went out but forgot all about it... oh well.
> The issue is that many platforms don't keep the directory structure, but
> seperate things into conf files, logs into /var/log, etc.  When someone
> upgrades their Apache and doesn't have a logs directory under server_root,
> it will all of a sudden choke.  Was even worse in 1.2.1 where the name of
> the lockfile it was trying to create was accidently ommitted.
> /usr/tmp or /var/tmp are bad because not all platforms have them.  Do a
> reasonable subset of all Unix platforms have a /tmp?  /tmp is probably the
> most likely to be local.
> I'm undecided if it is worth changing the default.
> > 
> > > Did you try using flock?  May need to use libucb which messes some
> > > things up at times.
> > 
> > No, but according to the manpage "flock() has been implemented on top of
> > fcntl(2)", so I wouldn't expect it to do anything differently.
> Grumble, mutter.  Upgrade to 2.6 and see if it fixes it.  For years I have
> been keeping a list of Solaris bugs that 2.6 is supposed to fix; will be
> interesting when it arrives here to see how many it actually does.  <g>
> I am disinclined to spend lots of effort to get around something that is a
> clear-cut braindamaged OS, but since your concerns about the child exit
> process are valid and something should be done there anyway, if whoever
> fixes that can work something reasonable in at that time, go for it.

View raw message