[Dovecot] graceful failure when some folders are not available...

[Steven F Siirila]

Did I miss a reply on this?  We're considering modifying Dovecot, but
would like opinions before going down the wrong path...

On Mon, Oct 08, 2007 at 04:39:25PM -0500, Steven F Siirila wrote:
> 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

-- 

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