(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.
"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.
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.
- 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?
- 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. :