On 5.8.2013, at 19.34, Thomas Hummel <hum...@pasteur.fr> wrote: > On Fri, Aug 02, 2013 at 03:38:47PM +0300, Timo Sirainen wrote: > >> Since you have only one Dovecot accessing the NFS, you don't need either >> mail_nfs_storage=yes or mail_nfs_index=yes. My guess is that by setting >> those to "no", you'll also solve this: >> >>> 2013-08-02T14:12:29+02:00 <0.5> XXXX-10(id10) /boot/kernel.amd64/kernel: >>> [lkf_delegate.c:2752](pid 46390="kt: dwt3")(tid=101282) >>> dev_local_lkf_unlock(): no lock entry present to unlock for resource: >>> 1:19d5:fdbe ;client: 0xa51cc3f444107 > > Thanks, I'll try that but that wouldn't be a good solution for when I'd want > to > use more dovecot servers anyway.
mail_nfs_*=yes wouldn't be a good solution even when you add more servers! Director is the only safe way to do it, and mail_nfs_*=yes isn't required with director. > Anyway, the problem seems harmless. But is it legit that dovecot try to unlock > non (or no more) locked files as it seems ? The NFS workarounds code is doing some ugly stuff. I thought it would have, but looking at the code it doesn't seem so. But still easier to debug if you first see if the problem is with the NFS workarounds or the lib-index code. With lib-index you could also use lock_method=dotlock to see if that works better (although performance will be slightly worse also then).
