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

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



Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

>> 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.

I don't know a proper solution. (I've made an ugly hack, just to prove
my assumption.)

In the other case, fetchnews must keep the new information it has
gathered in such a way, they can later be merged into the groupinfo
file even if another process changed it in between.

> 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)):

The auxiliary lockfile must be on the same filesystem as the real
lockfile, so it should be in the same directory, not in /tmp.

> 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.

If someone mounts /var/spool/news over NFS, he should have a unique
hostnames. Some examples may be found in mail software. (Debian
requires dotlocking and fcntl() locking of mailboxes.)

Stale lockfiles must be recognized and deleted (if too old).

>> 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.

But this is currently done by the leafnode programs.

>> I think the .overview files may also be put under some locking policy.
>
> Why should that be useful?

The may also get messed if written simultaneously by more than one
process. One 'global' lock may be sufficient.

If leafnode 2.x will insert locally posted articles directly into the
spool, safe locking will be absolutely necessary. Care should also be
taken that the newsgroup directories themselves won't get messed due
to race conditions.

Stefan


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