[Dovecot] FreeBSD, Dovecot and ZFS

[Jason Lock]

At  9PM +0000 on 12/02/13 you (Jason Lock) wrote:
> Mail Issues - FreeBSD
> 
> Hello, my apologies if this may be the wrong forum but hoping that 
> maybe someone might be able to provide some insight.

>> This may turn out to be something better addressed on freebsd-stable, but this is a perfectly good place to start.

Thank you for your reply.

> Have a very sporadic and strange issue with our mail servers running 
> Dovecot on FreeBSD.  There are three servers hosting Dovecot with 
> FreeBSD as the underlying operating system.  All three connect to a 
> NAS server, again running FreeBSD and ZFS.

>> Over NFS, I assume? What version, what mount options, and what type of authentication? 

Yes, using NFSv3 to attach the share from the NAS to each of the POP3/IMAP servers.  Only mount options set are RW.  Not authentication in place, NAS and POP3/IMAP Servers share VLAN just for the NAS connections.

>> What locking strategies is Dovecot using? 

In dovecot using the following:

dotlock_use_excl: no
mail_nfs_storage: yes
mail_nfs_index: yes
lock_method: dotlock

>> Are there any suspicious messages in syslog on either machine?

Nothing specific.

> When the specific issue occurs, clients connecting to check mail via
> POP3 or IMAP experience long delays and timeouts.  To the point where
> POP3 Logins fail due to the timeouts.  The issue is further compounded 
> by clients increasing the number of attempts to check mail.

>> Are the delays happening before or after login?

Delays appear during login, username gets passed but then timeouts after the password is sent.

>> If you can provoke this and get a 'procstat -k' for the relevant dovecot process this might be helpful. If 'long' delays means >> several minutes, running something along the lines of 'procstat -k $(pgrep -U dovecot -U doveauth)' every minute or so for a >> while might be one way to catch this, though this will collect a lot of data rather fast so you will need some way to locate the >> relevant entry.

Will look to capture that information if possible, have not been able to re-create the situation in which the issue occurs.

>> Ben