Re: Policy wrt mail lockfile (section 4.3)
On Fri, 20 Jun 1997, Lars Wirzenius wrote:
> [ Please don't Cc: public replies to me. ]
>
> John Goerzen:
> > Why are we using dotfile locking only? There are much better
> > mechanisms (flock, etc.) that should be used instead. I can see no
> > place where dotfile locking would work and flock-style locking would fail...
>
> NFS. Scripts that use procmail's lockfile.
>
> (If it doesn't already, the policy manual should explain the
> reasons behind policy. I'd check if it does, but I don't have
> a copy and am offline.)
The current policy manual (2.1.3.3) only says:
> Mailboxes are locked using the username.lock lockfile convention, rather
> than fcntl, flock or lockf.
This is buggy since it's not working over NFS. (I'm running into problems
every few days since I use sendmail/procmail/pine over a NFS mounted
/var/spool/mail !)
That's the exact reason why I started this discussion again.
AFAIK, there is at least one safe way to lock a file over NFS. The
procedure is partially explained in the open(2) man page and is also
implemented, for example, in your "publib" library.
Since the procedure is not that simple, I suggested to provide a shared
library that the other packages could be linked against, so that not every
maintainer has to program this on his/her own (this is likely to produce
new bugs!). And I suggested to produce "modules" for Perl/Python etc.
Someone else mentioned that the UN*X (at least Linux) world is laking such
a library and we should therefore build not a debian specific lib, but a
new "upstream library" which can be used by the other distributions as
well. IMHO, that's a very good idea.
Note, that all programs will have to use the same locking mechanism (this
has been discussed before). Thus, we should implement the simpliest
available algorithm that is NFS-safe, since a few maintainers will
probably need to hand-code this themselves (for example, for other
programming languages, etc.).
There are also tools available, that do locking, for example "lockfile" in
the procmail package. However, calling this program with "system" produces
IMHO too much unnecessary overhead and the source code of this program is
a bit to complicated to force all our developers to implement this.
IMHO, the code in "publib" looks very good. I suggest that we extract the
necessary files and put them together in a new package, called
"liblockfile" (or similar). This package should install a shared library
"liblockfile.so" that contains a few necessary commands to
lock/unlock/test a file.
In addition, we could create a new "lockfile" binary (just as in procmail)
that can be used by shell scripts or other programs (via "system").
We'll also provide "modules" for Perl/Python/etc.
Any comments?
(I feel like I presented these arguments several times now on this list,
but we've not got any results so far.)
Thanks,
Chris
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Don't know Perl? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: