[Dovecot] 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:
- Does dovecot user need to be a member of the mail group?
- 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:
- Does dovecot user need to be a member of the mail group?
No. Don't ever give any kind of permissions to "dovecot" user.
- 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)?
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.
- 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
On Thu, 2010-03-25 at 16: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.
Hmm....sorry, I should have mentioned - /var/mail is actually local - only the /home bits are NFS mounted. Is that even more concerning?!
/var/mail is still a mount point I think?
Anyway, if your INBOXes are on local server, I guess there's only a single server accessing users' mails then? If that's the case, just set mail_nfs_*=no and be happy.
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?!
/var/mail is still a mount point I think?
It is indeed!
Anyway, if your INBOXes are on local server, I guess there's only a single server accessing users' mails then? If that's the case, just set mail_nfs_*=no and be happy.
I think this is where our some what complicated system is an issue - mail that goes into /var/mail is only because the user's home directory is over quota and so the mail cannot be delivered into ~/Mail/inbox. We used to have a script that would go round daily and rescue /var/mail bits (when we also used UW-IMAP), but the mbox_snarf plugin is a nice way to do this in a more user-friendly manner. No users are reporting any issues here, even those referenced with the nfs_flush_file_handle_cache_dir errors, so we'll ignore that one for now.
BTW, and I'm sure you know and have heard this before - but the difference in the demands on the hardware between Dovecot with its indexes and UW-IMAP accessing some huge mboxes is huge - insanely so. All the theory in my head from reading about Dovecot said it should be, but nice to see that played out in reality. Quote of the day: "my inbox is quicker than its ever been". :-)
Thanks for your time ~~ 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
participants (2)
-
Ade Fewings
-
Timo Sirainen