[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:
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.
None of these matter.
No. Don't ever give any kind of permissions to "dovecot" user.
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)?
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.
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
It is indeed!
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