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

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Stefan Wiens <s.wi@xxxxxxx> writes:

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

That's what the template is for. However, I'm not sure if there is a
proper function ATM, I'd have to check later today. (Perl has a decent
module that returns the file name AND the open file descriptor.)

If there is a better approach to generate lockfiles that is NOT prone to
races itself, that's fine. 

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

Detecting the "stale" state is difficult across multiple machines since
you cannot easily look at the other box's pids. 

> > A process must not unlink a lock file it does not own.
> 
> But this is currently done by the leafnode programs.

If so, that's a bug. Who does it, when and why? 

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

True. This leads us to the gory details of transactional consistence,
cache coherence if file contents are kept in memory and so on. 

I'm wondering if a central daemon that leafnode uses to cache overviews,
request changes to the overview and/or news spool (post, cancel) would
be good. I don't mean to turn leafnode into a monolithic software,
that's the wrong way. I mean to add a daemon that only handles the news
spool and that leafnode (nntpd) and fetchnews query. It could
incorporate data base maintenance (filtering and texpire functionality).

-- 
Matthias Andree

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