Re: Policy wrt mail lockfile (section 4.3)
This sounds good to me. When finished, we should announce this
on c.o.l.a. and try to see if the Red Had folks will adopt it as
well. If we both adopt it as policy, then it will live on forever!
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
>
> 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 .
>
--
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: