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

[Stefan Wiens <s.wi@xxxxxxx>]

Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

>> When, in nntpd.c, a check on the return value of unlink() is added, 
>> and several articles are posted in a short period, there are messages
>> that unlink() failed. 
>
> THAT were the spurious messages I have seen occasionally. Heck. I'm
> getting a clue how broken leafnode really is. :-(
>
>> Another process had done that before. The program itself had locked a
>> dead file...
>
> "Must not happen." A process must only unlock if it has obtained the
> lock on its own.

It's more delicate. The process that unlinks the lockfile really has
the lock (except the fetchnews child). But unlink() primarily deletes
the /filename/. The file itself stays in existence as long as any
process has it open. Leafnode first opens the lockfile, then waits
until it obtains the lock. The lock is granted after the first process
has terminated.

Because the filename doesn't exist anymore, the next invocation of
lockfile_exists() will create a new lockfile, distinct from the first
one. The result is two processes owning different lockfiles.

One time, an overview file got corrupted in such a way, texpire
segfaulted upon reading it. The next leafnode process fixed it, so I
couldn't make a copy of the offending file :-(

> If the lock files are being respected everywhere, i. e. lockfile_exists
> is split into try_lock, obtain_lock, and there is a new function,
> un_lock, then everything should be fine again.

The current lockfile_exists() call should be sufficient, if the
lockfile is established in a safe manner, including removal of a stale
lockfile. Then an unconditional unlink() does no harm. The effects of
incorrectly removing a stale lockfile may be minimized by additional
fcntl-locking another file, whose inode number won't change under
normal conditions.

> Not the best performance possibly, but clean.

This is only done once per process, so it won't cause a noticeable
performance impact.

I still have no idea how the problem concerning the two fetchnews
processes could be solved properly.

Stefan


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