Hello Timo,
I'm running
a single instance of dovecot-2.1.15
on a single host running 8.3-RELEASE-p3 FreeBSD amd64
mailboxes (Maildir), control files and indexes are on NFS (v3,tcp)
mail_nfs_storage = yes
lock_method = fcntl
[didn't touch the following]
# Mail index files also exist in NFS. Setting this to yes requires
# mmap_disable=yes and fsync_disable=no.
mail_nfs_index = yes
served by an Isilon s200 node (OneFS 6.5.5.22)
procmail delivers in the same location through postfix-2.8.7
The filer shows *a lot* of such messages :
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
Corresponding file may be a message, a maildir, an index, ...
I can experience the same message with a simple fcntl C program which tries to
unlock an NFS file without prior locking of it.
However, the problem occurs only on a FreeBSD client (I tried the old nfs
client and the new (mount_newnfs), not on a 2.6.32-358.11.1.el6.x86_64 CentOS
release 6.4 (Final) Linux release.
So my guess is that dovecot has some safety mechanism which tries to unlock
locked files, maybe after some timeout and that, in the case of a an already
unlocked file, the FreeBSD client sends the unlock RPC request to the server
anyway whereas the linux client does not, noticing there isn't anything to
unlock.
Can you help me explaining such a behavior ? Are those "unlock a file with
no
prior lock" made on purpose or is it a bug ? Would it be an application or
a
RPC bug ?
Can you think of another reason ?
Thanks
--
Thomas Hummel | Institut Pasteur
<hummel at pasteur.fr> | Groupe Exploitation et Infrastructure