Several issues with 2.1.13
John Alton Tamplin
jtampli at sph.emory.edu
Mon Jun 9 15:53:51 EDT 2003
Wil Cooley wrote:
>The upgrade wasn't entirely smooth; I wrote up some notes about what I
>did: http://nakedape.cc/wiki/index.cgi/CyrusImapNotes in case someone
>else wanders along this path... The biggest issue was that ctl_cyrusdb
>wasn't able to read my old mailboxes.db file; I reverted to my old
>installation and dumped the database to a flat file and it went okay.
>For some reason that I don't understand, I had to remove the
>/var/lib/imap/db directory for the rebuilding of the database to work
If the version of db is different, you can't just expect to use the
binary database files and logs. Dumping the contents to a text file,
wiping the transaction logs, and then reloading them is the safest way.
>'rehash full' did very strange things; it only created directories of
>A-Z, none of a-z and my own mailbox information was under 'I/' in both
>the mailbox spool and the '/var/lib/imap/user' directory. As a result,
>I had to disable 'hashimapspool', which Simon's RPMs enabled by default.
You should have had A-W, not Z (23 is a prime to give better
distribution of the hash values between directories) -- full hashing
chooses a hash directory based on the complete mailbox name rather than
just the first character. Traditional hashing tends to overload some
directories while leaving others almost empty.
mbpath will give you the path for the mailbox, or just ls -ld
/cyrus/*/user/wcooley (for example). If you have less than a thousand
mailboxes, there is no need to worry about hashing. Otherwise, you will
likely get poor performance with long namei lookups.
>Finally, I have a customer that's a small ISP that's currently running
>2.0.16. I'm going to upgrade regardless, just so I can bounce messages
>delivered through LMTP to boxes that are over-quota. However, I
>recurrent problem we have is with POP3 users (which everyone is) who
>lose their connection (usually because of problems with dial-up). The
>pop3d stays running and locks the mailbox for 15 minutes or so, causing
>lots of support calls and grumbling. I'm guessing the connection stays
>in TIME_WAIT for this period, but 15 minutes seems like a long time for
>it to stay open. I see the 'poptimeout' setting that might help, but
>even 10 minutes might be too long. (This 15 minutes could be only 10
>minutes already; I'm just being told this by the guy who does support.)
>Will anything that's changed between 2.0.16 and 2.1.13 help assuage this
In this day, is there really any good reason to continue using POP?
There are so many problems with it (including support issues when people
downloaded their mail to one computer and wonder why they can't access
it from another) it seems best to retire it.
When the user calls up complaining about this, that gives you a perfect
opening to convince them to move to IMAP.
John A. Tamplin Unix System Administrator
Emory University, School of Public Health +1 404/727-9931
More information about the Info-cyrus