[Dovecot] 1.0.rc10 status report

[David Lee]

(Background: Relatively new to dovecot; looking to do transparent
replacement of long-established UW-IMAP on cluster of Linux boxes which
NFS-mount a shared "/var/spool/mail".)

With rc8, where I had already increased "login_max_processes_count" from
default 128 to 1024, we had still hit the issue of too many logins
crashing dovecot, so that trial had only lasted a couple of hours.

With rc10, I doubled this to try to avoid the problem (I didn't want to
risk testing the new code that addressed the problem... sorry!).  We ran
for almost a full working day.  Good!  Because of a few issues (below) I
then backed off.


1. "User unknown":  We use NIS for our passwd information.  On the earlier
rc8 test we had had several occurences of "User unknown" (from "deliver")
giving "dsn=5..." for perfectly valid users.  So for this rc10 test I
applied a local patch so these were reduced to "EX_TEMPFAIL" (dsn=4...).
(This was triggered, as epected, a few times and subsequent delivery
attemtps succeeded.)  I strongly suspect that this is some sort of issue
with FC5, probably "nscd" and nothing to do with dovecot.  Hints would be
nice, but from the dovecot perspective you may probably ignore this item.


2. For one particular user, the "deliver" consistently gave:
      Failed to create storage for '...' with mail 'mbox:/HOME_DIRECTORY_USED_BUT_NOT_GIVEN_BY_USERDB:INBOX=...

I think this is ultimately due to something strange in the user ".forward"
file.  I'd be delighted to follow this up with anyone else who might have
seen it.  Although in one sense we may be drifting off-topic, in another
sense I suspect that there is scope for adjusting "deliver" to handle this
more gracefully.


3. There were several occurences of:
      IMAP(...): file ../../../../../src/lib-storage/index/mbox/mbox-sync-rewrite.c: line 405 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space)
      child 30842 (imap) killed with signal 6

This looks particularly awkward.  Any thoughts?


4. There were two occurences of:
      IMAP(...): file ../../../src/lib-index/mail-index.c: line 1801 (mail_index_move_to_memory): assertion failed: (index->fd == -1)
      child 20493 (imap) killed with signal 6

Again, this looks particularly awkward.  Any thoughts?



For these last two items, note that the indexes are currently NFS-shared
alongside the INBOX area.

I'm still not clear on how to regard the concept of indexes, as applied to
a small cluster of machines, and handling simultaneous updates to INBOXes
(analogous to the vital importance of INBOX locking for such updates).

If one imagines the IMAP daemon (and pop and deliver) as file-clients of
the (NFS-shared) INBOXes on a fileserver, do the indexes belong very close
to the INBOXes (fileserver) or the dovecot software (file client)?  So
should I have the indexes on the fileserver (one instance), or should they
be on each cluster machine's private storage (possibly several instances;
one per cluster machine)?  I've got them on the server; would they be
better on the cluster clients?  (Might that be the cause and fix of these
two problems?)


-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :