Re: [leafnode-list] writeactive() not updating mtime?

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Stefan Wiens <s.wi@xxxxxxx> writes:

> The fetchnews child process doesn't inherit the lock from its parent,
> but nevertheless updates the groupinfo. When leafnode read the
> groupinfo stat(), it wasn't changed yet. No reason to reread it.
> Later, fetchnews and leafnode concurrently wrote the groupinfo.
> 
> The lock should be handed over seamlessly from the fetchnews parent to
> its child process.

How do you "hand over" the lock? The lock terminates as the locking
process (the parent) terminates. The child would have to lock the file
anew, which is prone to race conditions.

The lockfile scheme should not rely on fcntl(2) or flock(2) at all since
these are prone to race conditions and other failures across NFS.

My Linux open(2) man page has information on how to safely lock files
across NFS (involves generation of a temporary file - bad if the various
mk*t*mp functions are broken - and link(2)):

(Linux' man page open(2)):
       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.
              If  link() returns 0, the lock is successful.  Oth­
              erwise, use stat(2) on the unique file to check  if
              its  link  count  has increased to 2, in which case
              the lock is also successful.

Note that hostname and pid are not enough for uniqueness since the
leafnode audience might not take hostnames too serious. A timestamp and
a random number should also be added.

> There is another locking problem: When one process unlinks the
> lockfile, another process may have it still open and later lock the
> 'zombie' file. 

A process must not unlink a lock file it does not own.

> I think the .overview files may also be put under some locking policy.

Why should that be useful?

-- 
Matthias Andree

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list