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.
My tests using a simple fcntl() C program (unlock a non-locked file) is giving me a hard time figuring out what conditions cause the file server to log this message :
On some Isilon node/destination IP combinations, I'd have the message, on other I wouldn't.
Still, it seems I cannot reproduce the problem on any other hosts (mounting this server) than the one running the dovecot server. Oddly enough, my fcntl test causes this message even with dovecot stopped, statd and lockd restarted and the filesystem un-and-re-mounted while the same setup (up to date via FreeBSD update, i.e. same base, same nfs client) would not make the server log the message.
Anyway, the problem seems harmless. But is it legit that dovecot try to unlock non (or no more) locked files as it seems ?
Thanks for your help.
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Groupe Exploitation et Infrastructure