[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [leafnode-list] writeactive() not updating mtime?
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).
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list