dovecot - Oct 2007 - graceful failure when some folders are not available...

Hi folks. Quick question in the hopes that someone knows the answer, before 
I dig in the code some more.

In testing a new setup with some long-term archival mbox-format mailboxes 
stored on an NFS mount, we've found the following: if the mount is 
unavailable for any reason, the user cannot log into their email at all. 
Dovecot says: "stat() failed with mbox foo" and dies. This is coming
from
the mbox sync checks. (It's possible the same happens with a maildir 
folder--I'm just specifying mbox because that's what we've tested
with so
far).

Is there a way to reconfigure this behavior? I could maybe see a fatal 
abort if the inbox is unavailable, but for other folders it seems rather... 
presumptuous. I have to think there's already a way to handle this more 
gracefully in the config and I'm just not seeing it.

Also, does anyone know offhand if this behavior is the same for folders 
that aren't in the default/inbox namespace? That would seem *really* wrong.

Any thoughts? Thanks much,

-Brian

On Wed, 2007-10-03 at 20:03 -0500, bhayden at umn.edu
wrote:
> Hi folks. Quick question in the hopes that someone knows the answer, before
> I dig in the code some more.
> 
> In testing a new setup with some long-term archival mbox-format mailboxes 
> stored on an NFS mount, we've found the following: if the mount is 
> unavailable for any reason, the user cannot log into their email at all. 
> Dovecot says: "stat() failed with mbox foo" and dies. This is
coming from
> the mbox sync checks. (It's possible the same happens with a maildir 
> folder--I'm just specifying mbox because that's what we've
tested with so
> far).
It shouldn't die. Maybe your client kills the connection?

I tested this by making the stat() call always fail with EIO:

x select inbox
x NO Internal error occurred. Refer to server log for more information.
[2007-10-06 04:24:48]
x status foo (messages)
x NO Internal error occurred. Refer to server log for more information.
[2007-10-06 04:24:58]

Or even if the mailbox is successfully opened and after that:

x noop
* NO Internal error occurred. Refer to server log for more information.
[2007-10-06 04:27:31]
x OK NOOP completed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20071006/40bdb0d2/attachment-0002.bin>

On Sat, Oct 06, 2007 at 04:28:20AM +0300, Timo Sirainen
wrote:
> On Wed, 2007-10-03 at 20:03 -0500, bhayden at umn.edu wrote:
> > Hi folks. Quick question in the hopes that someone knows the answer,
before
> > I dig in the code some more.
> > 
> > In testing a new setup with some long-term archival mbox-format
mailboxes
> > stored on an NFS mount, we've found the following: if the mount is
> > unavailable for any reason, the user cannot log into their email at
all.
> > Dovecot says: "stat() failed with mbox foo" and dies. This
is coming from
Perhaps "dies" was too strong.  In fact, Dovecot does not die, but the
client perceives such as it is told this upon trying to log in:

	"The current command did not succeed. The mail server responded:
	 Internal error occurred. Refer to server log for more information."

And in fact your tests (below) reproduced this.  The problem with this is
that if even one file or directory within the user's IMAP folder space is
currently unavailable (due to an NFS server being down), the user cannot
log in at all to access any of their other folders.  In out scenario, we
would prefer that the user simply not see the folders (treat the error the
same as "file not found").  BTW, the errno seen is ETIMEDOUT (we are
soft
mounting the NFS filesystem in question).  Any thoughts on how we can
accomplish this?  We don't normally expect this NFS filesystem to become
unavailable, but when it is, we don't want it to prevent all users from
being able to log in, since this NFS filesystem only holds folders of an
archival nature.
> > the mbox sync checks. (It's possible the same happens with a
maildir
> > folder--I'm just specifying mbox because that's what we've
tested with so
> > far).
> 
> It shouldn't die. Maybe your client kills the connection?
> 
> I tested this by making the stat() call always fail with EIO:
> 
> x select inbox
> x NO Internal error occurred. Refer to server log for more information.
[2007-10-06 04:24:48]
> x status foo (messages)
> x NO Internal error occurred. Refer to server log for more information.
[2007-10-06 04:24:58]
> 
> Or even if the mailbox is successfully opened and after that:
> 
> x noop
> * NO Internal error occurred. Refer to server log for more information.
[2007-10-06 04:27:31]
> x OK NOOP completed.
> 


-- 

Steven F. Siirila			Office: Univ Park Plaza, Room 750
Internet Services			E-mail: sfs at umn.edu
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota			Fax: (612) 626-7593