[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dot-locking



>>>>> "Bruce" == Bruce Perens <bruce@pixar.com> writes:

    Bruce> The open-and-then-link as described by Phil is better than
    Bruce> just open for NFS.

 The open man page says:
8<----------------------------------------------------------------->8
	  O_EXCL When used with O_CREAT, if the file already  exists
		    it  is  an error and the open will fail.  O_EXCL is
		    broken on NFS file systems, programs which rely  on
		    it for performing locking tasks will contain a race
		    condition.  The solution for performing atomic file
		    locking using a lockfile is to create a unique file
		    on the same fs (e.g.,  incorporating  hostname  and
		    pid),  use  link(2)  to make a link to the lockfile
		    and use stat(2) on the unique file to check if  its
		    link  count  has  increased  to  2.  Do not use the
		    return value of the link() call.
8<----------------------------------------------------------------->8

 The Debian 'publib' library has a subroutine in it for creating
lockfiles, (Written by Lars Wirzenius), that uses this method. I was
unable to find any existing Perl libraries to do this, but did come
across the 'lockfile' command that comes with 'procmail'.  I assume
they use this algorithm, though I have not verified it by looking for
myself.

 'lckpwd', the password locking routine in libc, is an interesting
function.  It does not perform the link, and therefore would not be
'nfs' safe.  I don't think it needs to be though, on most systems,
does it?  A 'transnames' patched system may well need 'nfs' safe
/etc/passwd locking.  There is a 'pragma weak' on the 'lckpwd'
functions...  I think this means that a LD_PRELOAD is allowed to
replace it, is that right?

 From reading in O'Reilly's 'UNIX Systems Programming for SYSVr4',
(pg. 156), I found that in SYSV, the 'flock' structure, which on Linux
is in <asm/fcntl.h>, contains a field for the system id (l_sysid) of
the computer holding a lock.  (This must be maintained in some sort of
list by the kernel... anybody know?)  Apparently the Linux nfs
implementation has not evolved to the point where a SysID has been
added, and this is why we must make lockfiles rather than using the
'fcntl', 'flock' or 'lockf'.

 I wonder how the flock.l_sysid is determined???  The number (a long)
would need to be shared by all of the computers involved.  How does it
get initialized/assigned?  Would that be in one of the configuration
files?  Is it a hash of the FQDN?  Hmmm.  Does anyone know?

Karl M. Hegbloom <karlheg@inetarena.com>
http://www.inetarena.com/~karlheg
Portland, OR  USA
Debian GNU 1.2  Linux 2.0.29t

Reply to: