dovecot - Mar 2010 - 1.2.11 nfs_flush_file_handle_cache_dir problems

Hi chaps

We're using the mbox_snarf plugin to snarf mail from /var/mail/%U to
~%U/Mail/inbox and using dotlocking on all accesses.  This is on Solaris
with NFS mounted home directories.

We're getting a few (very few) of these for just a couple of users:

Error: nfs_flush_file_handle_cache_dir: rmdir(/var/mail) failed: Device busy

Which, having searched, I see some discussion of in the past, but not
with 1.2.  We're using:

mail_privileged_group = mail

For the /var/mail 'inboxes', which I thought would tackle this problem. 

Couple of questions, if you don't mind:
1. Does dovecot user need to be a member of the mail group?
2. Does this error message represent a real problem that needs solving? 
It's very strange how rare it is and that only a few select users have
encountered.

Full dovecot.conf below:
> # 1.2.11: /usr/local/dovecot-1.2.11-b/etc/dovecot.conf
> # OS: SunOS 5.10 sun4v
> log_path: /usr/local/dovecot/var/dovecot.log
> protocols: imap imaps pop3 pop3s
> listen(default): *:143 *:10143 *:20143 *:30143 *:40143 *:50143
> listen(imap): *:143 *:10143 *:20143 *:30143 *:40143 *:50143
> listen(pop3): *:110
> ssl_listen(default): *:993 *:10993
> ssl_listen(imap): *:993 *:10993
> ssl_listen(pop3): *:995
> ssl: no
> ssl_cipher_list: MEDIUM:!LOW
> disable_plaintext_auth: no
> shutdown_clients: no
> login_dir: /usr/local/dovecot-1.2.11-b/var/run/dovecot/login
> login_executable(default):
> /usr/local/dovecot-1.2.11-b/libexec/dovecot/imap-login
> login_executable(imap):
> /usr/local/dovecot-1.2.11-b/libexec/dovecot/imap-login
> login_executable(pop3):
> /usr/local/dovecot-1.2.11-b/libexec/dovecot/pop3-login
> max_mail_processes: 1024
> verbose_proctitle: yes
> mail_privileged_group: mail
> mail_location: mbox:~/Mail:INBOX=/var/mail/%u
> mail_debug: yes
> mmap_disable: yes
> mail_nfs_storage: yes
> mail_nfs_index: yes
> lock_method: dotlock
> mbox_read_locks: dotlock
> mbox_write_locks: dotlock
> mail_executable(default): /usr/local/dovecot-1.2.11-b/libexec/dovecot/imap
> mail_executable(imap): /usr/local/dovecot-1.2.11-b/libexec/dovecot/imap
> mail_executable(pop3): /usr/local/dovecot-1.2.11-b/libexec/dovecot/pop3
> mail_plugins: mbox_snarf
> mail_plugin_dir(default): /usr/local/dovecot-1.2.11-b/lib/dovecot/imap
> mail_plugin_dir(imap): /usr/local/dovecot-1.2.11-b/lib/dovecot/imap
> mail_plugin_dir(pop3): /usr/local/dovecot-1.2.11-b/lib/dovecot/pop3
> auth default:
>   verbose: yes
>   debug: yes
>   passdb:
>     driver: pam
>   passdb:
>     driver: passwd
>     args: blocking=yes
>   userdb:
>     driver: passwd
>     args: blocking=yes
> plugin:
>   mbox_snarf: ~/Mail/inbox
Much appreciate your time, it has made an amazing difference here, I'm
just seeking absolute perfection I think (well, mbox perfection anyway).

~~
Ade


-- 
Centre for Advanced Software Technology Limited is a limited company registered
in England and Wales.
Postal Address: C.A.S.T. Limited, Technium CAST, Ffordd Penlan, Parc Menai,
Bangor, Gwynedd. LL57 4HJ.
Registered Number: 04473521. Registered Office: Finance Office, Bangor
University, College Road, Bangor, Gwynedd. LL57 2DG.
www.techniumcast.com

On Thu, 2010-03-25 at 15:16 +0000, Ade Fewings wrote:
> Error: nfs_flush_file_handle_cache_dir: rmdir(/var/mail) failed: Device
busy
Dovecot tries to flush NFS cache by doing this rmdir(). It is intended
to fail, but not with EBUSY. I guess /var/mail is your NFS mount root?
That's why this is failing. There's really no good way to solve this.
> Which, having searched, I see some discussion of in the past, but not
> with 1.2.  We're using:
> 
> mail_privileged_group = mail
None of these matter.
> Couple of questions, if you don't mind:
> 1. Does dovecot user need to be a member of the mail group?
No. Don't ever give any kind of permissions to "dovecot" user.
> 2. Does this error message represent a real problem that needs solving? 
> It's very strange how rare it is and that only a few select users have
> encountered.
It happens when Dovecot doesn't find the expected mbox file from the
directory, so Dovecot tries to flush NFS cache to see if the file was
just created. Is something deleting the /var/mail/$user file for those
problem users (e.g. some non-Dovecot MUAs do that)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20100325/c19469b3/attachment-0002.bin>

>> Error: nfs_flush_file_handle_cache_dir: rmdir(/var/mail) failed: Device
busy
>>     
> Dovecot tries to flush NFS cache by doing this rmdir(). It is intended
> to fail, but not with EBUSY. I guess /var/mail is your NFS mount root?
> That's why this is failing. There's really no good way to solve
this.
>   
Hmm....sorry, I should have mentioned - /var/mail is actually local -
only the /home bits are NFS mounted.  Is that even more concerning?!

Only procmail could come along and touch the mbox as the LDA. 
>> 2. Does this error message represent a real problem that needs solving?
>> It's very strange how rare it is and that only a few select users
have
>> encountered.
>>     
> It happens when Dovecot doesn't find the expected mbox file from the
> directory, so Dovecot tries to flush NFS cache to see if the file was
> just created. Is something deleting the /var/mail/$user file for those
> problem users (e.g. some non-Dovecot MUAs do that)?
Could it be erroring because the /var/mail slice is not NFS mounted?  
Perhaps not using mbox_snarf would therefore avoid this problem and we
could revert to our traditional script to move mail once user quotas
have been sorted.

Thanks
Ade


-- 
Centre for Advanced Software Technology Limited is a limited company registered
in England and Wales.
Postal Address: C.A.S.T. Limited, Technium CAST, Ffordd Penlan, Parc Menai,
Bangor, Gwynedd. LL57 4HJ.
Registered Number: 04473521. Registered Office: Finance Office, Bangor
University, College Road, Bangor, Gwynedd. LL57 2DG.
www.techniumcast.com