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

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Stefan Wiens <s.wi@xxxxxxx> writes:

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

You're missing the point then. 

I'm trying to encapsulate the entire lock handling to allow for EASY
later replacement. The lock file simply must not be unlinked() before
it's closed.

> Leafnode first opens the lockfile, then waits until it obtains the
> lock. The lock is granted after the first process has terminated.

Wrong approach, broken by design.

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

It does not matter what happens because of unsafe use of lock files.

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

No, it's not sufficient, since it's prone to abuse like seen
currently. It does harm. See above.

Let me revise my suggestion (I will come up with a function to handle
lock files tomorrow, probably.) and suggest these function names:

lock_nowait   (return error if a "living" lock file is present)
lock_wait     (block until lock file obtained)
lock_wait_max (block until lock file obtained, with timeout)
lock_release  (obvious)

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

You're playing games and are trying to handle special cases you don't
need to handle.

lock_try/wait/wait_max can of course exclusively fcntl-lock the lock file. A process
trying to unlink the file must obtain an exclusive fcntl-lock BEFORE it
unlinks.

Note this will either need to be restricted to one host or it will
require NFS-safe locking, i. e. won't working with user-space nfsd on
Linux.

That's simple and safe.

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

Implicit. Consider my suggestions and find holes in the concept. I'll go
code pretty soon. I'll release that code under the GPL v2; if Cornelius
desires so, I'll add an explicit permission that disables the
infiltration clauses for use in leafnode.

-- 
Matthias Andree

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