intermachine flocking

Dominic Mitchell dom at
Wed Dec 14 20:07:27 GMT 2005

On Wed, Dec 14, 2005 at 09:53:20AM +0000, Peter Haworth wrote:
> On Tue, 13 Dec 2005 16:38:02 +0000,  (Dominic Mitchell) wrote:
> > On Tue, Dec 13, 2005 at 04:24:51PM +0000, Simon Wistow wrote:
> > > Of course flock() doesn't work across NFS. Is the only solution to
> > > this a flock daemon?
> Depending on your kernel version, it can actually appear to work on
> Linux. However, although it might seem that you can lock remote files,
> those locks are only visible to local processes. When everyone
> complained about the relatively recent removal of Linux's apparent
> flock() over NFS capability, they failed to realise that it had never
> really worked properly.

FreeBSD did work like that for a long while.  I think that 5.0+ has a
proper implementation of the network lock manager though.  ie: talks to
other locking daemons.

> > If you're in Perl, flock() is probably implemented using
> > fcntl(), which is supported over NFS. Run strace over a test
> > script to verify.
> Perl defaults to using flock() for flock(). It only falls back to
> using fcntl() if flock() isn't available. This is done by Configure,
> which doesn't actually test that flock() works, so you have to re-
> Configure with -Ud_flock if you want to force perl to use fcntl().
> Note that the semantics are different, though; you can't get an
> exclusive lock with fcntl() unless you've opened the file for writing.

Darn... I was confused about this.

> > If it's not, then you need to do jiggery pokery with lockfiles. This
> > involves [complex stuff]
> Or you could just call fcntl() from perl. It means using unportable
> pack() construction of the struct flock, but it does work.

Sounds like a useful bit of XS would be interfacing nicely with XS...


More information about the mailing list