On Wed, 2010-09-15 at 10:12 +0200, Axel Luttgens wrote:
Here, with dovecot 2.0.2, client_limit seems to default to 1 for services imap and pop3. Trying client_limit=10 for imap, I get:
dovecot[46911]: imap(testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service
Yes.
dovecot[46286]: lmtp(46334, testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service
and one needs to define client_limit=1 for lmtp as well.
Yes, this is intentional. client_limit=1 default is good for pop3/imap, but for lmtp and non-mbox format a larger client_limit is better because latency doesn't matter that much.
This behavior seems to have been enforced in mbox-storage.c with http://hg.dovecot.org/dovecot-2.0/rev/28c3486864f6, and comes with following comment: "/* we can't handle locking related problems. */".
This is thus rather new. But I couldn't find any information on the list related to those "locking problems". Is it really needed to be so stringent with mbox format? Or was it jut intended to be a temporary workaround?
The problem is that with mbox format the mbox file can be locked for a long time. So for example two clients handled by the same process may attempt to write to the same mbox:
- Client 1 write-locks mbox file and goes back to ioloop waiting for the message data to arrive.
- Ioloop starts handling client 2 connection, which also tries to save message to same mailbox and tries to write-lock the same mbox file.
Now the second client keeps blocking on the write-lock and waiting for client 1 to release the lock, but since 1 is handled by the same process, this won't happen.
This problem doesn't happen with any other mailbox format.
Maybe some day in future there's a way to avoid this by having the code notice early that the mailbox is locked and go back to ioloop instead of block.