============================================================================ A comment from the liblockfile maintainer: liblockfile locking *is* NFS safe. That is, the *lockfile* it creates is created in such a way that only one party trying to acquire the lock is going to get it. The issue about the mailspool not being in-sync with remote servers because of NFS attribute caching is a real one, but that isn't something the routines in liblockfile can do something about. Remember that the routines in liblockfile just _create a lockfile atomically_. That's all. They do not magically flush the NFS cache for some other file (in this case, the mail spool). In fact that is very hard if not impossible. The MTA or MUA itself is responsible for flushing the kernels NFS attribute cache after acquiring the dotlock using liblockfile. If the MUA or MTA doesn't do this, that's a bug in that application. Read the manpages included with liblockfile for details. (may 2001) ============================================================================ If you are trying to use mutt using /var/spool/mailboxes mounted by NFS (on Linux 2.2 NFS servers) you might have encountered some problems like: 1.- folders are opened read-only 2.- it takes quite some time for mutt to open folders, and it displays a "fcnlt lock(x)" message on startup (with a X a number that keeps increasing to a limit) This is due to file locking (more on this below), specifically to the liblockfile1 package (no fix yet) and mutt's fcntl locking. Mutt in fact does file locking the best (portable) way. Until a fix is available you can only disable this problem by setting the 'nolock' option on the /etc/fstab entries of your client. Something like: myserver:/var/spool/mail /var/spool/mail defaults,nolock 0 0 But *BEWARE* this might cause problems if your access simultaneously a mailboxes from two different clients, since there is no locking done this might cause file corruption, use with CARE. The details are explained in this email message: Date: Fri, 29 Oct 1999 22:58:54 +0200 From: Roland Rosenfeld To: Fernando Alegre Cc: Miquel van Smoorenburg , "Marco d'Itri" Subject: Re: Is dotlocking safe? On Fri, 29 Oct 1999, Fernando Alegre wrote: > After a few mail interchanges with Marco D'Itri about reading mail > through NFS with mutt he provided me with the whole thread of a > discussion you had about that a month ago. I have read it fully a > couple of times but I still cannot infer a conclusive answer to my > question: > > Is dotlocking safe for reading mail through NFS? That depends on the kernels you are using. If both machines are running Linux kernel 2.0.*, dotlocking is safe (I didn't try what happens if the client runs 2.0.* and the server runs something different, this may also be safe, but I didn't test it). If the client runs kernel 2.2.*, dotlocking is _not_ safe. This is caused by a new caching mechanism in 2.2.*, which doesn't offer a chance to find out whether a file changed on the server. So the following situation may happen: 1) Client reads mailbox 2) Server changes mailbox 3) Client locks mailbox 4) Client writes mailbox 5) Client unlocks mailbox Between 1) and 4) the client doesn't contact the server, so it doesn't notice, that 2) changed the mailbox, so the changes in 2) are overwritten in 4). This means that you may lose mail. The problem is, that you lock a file foo, but you only access the file foo.lock (or something like this). To work around this problem, kernel 2.2.* uses the following trick: the fcntl() locking mechanism does not only lock the file foo, but it also flushes the cache of this file. So if you do a fcntl() lock in 3), this means that the cache is flushed and the client will notice in 4), that the mailbox was changed in 2). This trick does not work, if you are using Kernel <2.2.13 on the client _and_ the nfs server does not support locking. With kernel 2.2.13 this problem was fixed. This mean, that with 2.2.12 on the client and 2.0.36 on the server, you will always lose mail! > If I use only dotlocking and not rpc.lockd, am I risking losing > mail? With kernel 2.2.* on the client: YES! > If that is the case, then I see no point in using dotlocking at > all. We could step over to use only fcntl() locking, but this requires a server which supports locking (the user space nfsd doesn't and I don't know, whether there are other Unixes which also doesn't support locking). So we need a combination of fcntl() and dotlock until the time, when every possible server supports locking. > I thought that was the whole purpose of liblockfile. There are multiple purposes of liblockfile: - It's an implementation which every other program can use without thinking about locking (okay, this is no longer true, until liblockfile 1.01 is not NFS safe, which is a bug!) - liblockfile1 supports a way to do dotlocking without setting the MUA SGID mail (liblockfile1 forks a small SGID mail program to create the lock file). At the moment our problem is, that liblockfile1 doesn't provide a NFS safe way of locking. This makes it quite unusable, unless programs using liblockfile do the fcntl()-locking part themselves. > I think this is an issue important enough that users need a > clear-cut explanation before tragedy arises. I fully agree, that's why I wrote an "important" bug report (#43491) against liblockfile1 (which was downgraded to "wishlist"), and also wrote an "important" bug report against debian-policy (#43529). You should also have a look at bug #43651, which introduces a policy change to require a combination of dotlock and fcntl() instead of simply pointing to liblockfile as a reference implementation (which was said to be NFS-safe, but isn't with kernel 2.2.*). This policy change will be in the new 3.1.0 policy, which should be released soon. When this happens, we can start filing "important" bug reports against all mail accessing programs, which lock mailboxes with dotlock only (or in some other nfs-unsafe way). Ciao Roland -- * roland@spinnaker.de * http://www.spinnaker.de/ *