On Fri, 2006-10-20 at 13:26 +0100, David Lee wrote:
- "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.
Yea. Dovecot only does a getpwent() call which can't really be used wrong.
- 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.
Is deliver executed from .forward file? In that case the HOME environment isn't set and deliver doesn't assume that it's going to deliver to the current local user, so it's not looking up the home directory by itself..
- 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?
In case you missed, this fixes it: http://dovecot.org/patches/1.0/dovecot-1.0.rc10-mbox-keywords-fix.patch
- 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?
The moving to memory code isn't perfect, but normally it shouldn't even be done. I think there are only two reasons:
Filesystem quota / out of disk space in general
mbox_min_index_size
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?)
Indexes contain metadata of the mailboxes, so if you're using multiple different computers to read/write to the same user's mailbox, then it's better to keep them in NFS.
If you can make only a single computer access the same user's mailbox most of the time then it's probably faster to keep them in local disk. Otherwise if you kept them in local disk in different computers you'd waste time in synchronizing the indexes separately for each computer that accesses the mailbox.