On Tue, 15 Oct 2013, Stephen R. van den Berg wrote: > This (locking problem) is not a bug in procmail, as it happens, locking over > NFS is tricky to get right, and it is the responsibility of the system > administrator to get it right using the correct statd/lockd > settings/configuration when mounting the filesystems. > > Procmail tries to accomodate for sysadmins messing up here, but it can only do > so if the said filesystems are available for testing at compile time. > If you are using a precompiled procmail and use filesystems configured worse > than the systems that were available during the compile time tests, procmail > can both hang or simply fail to lock. > > This bug is not a bug in procmail and should be closed.
I have just closed this bug because the submitter said he could not reproduce it anymore. I just wanted to comment on your reply: IMHO, the idea that sysadmins should build procmail and perform compile time tests may make sense in a *general* way, but IMHO it does not fit very well with Debian spirit. In Debian, it was determined a long time ago that the correct way to perform locking was fcntl() + dot locking, which apparently is the thing that works well (or the only thing that has some possibility to work) with Linux. This is also written in Debian policy: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-mail-transport-agents All Debian MUAs, MTAs, MDAs and other mailbox accessing programs (such as IMAP daemons) must lock the mailbox in an NFS-safe way. This means that fcntl() locking must be combined with dot locking. To avoid deadlocks, a program should use fcntl() first and dot locking after this, or alternatively implement the two locking methods in a non blocking way[100]. Using the functions maillock and mailunlock provided by the liblockfile*[101] packages is the recommended way to realize this. For this reason, the Debian procmail package has LOCKINGTEST=100. This should effectively make unnecessary that Debian users do any build time tests. In general, asking users that they should build their own packages is contrary to Debian philosophy. Our job is precisely (among other things) trying to avoid that. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
