[Dovecot] 1.0.beta6 released
Fixes, mostly:
* The login and master usernames were reversed when using
master_user_separator (now the order is UW-IMAP compatible).
* Killing dovecot master process now kills all IMAP and POP3
processes also.
+ -a parameter to dovecot prints now all settings that Dovecot uses.
-n prints all settings that are different from defaults.
+ Added pop3_lock_session setting
+ %M modifier returns string's MD5 sum. Patch by Ben Winslow
- PLAIN SASL authentication wasn't working properly, causing failed
logins with some clients (broken in beta4)
- Fixes to Maildir++ quota, should actually work now
- Don't crash if passwd-file has entries without passwords
(eg. deny=yes databases)
- Fixed prefetch userdb to work nicely with other userdbs
- If master process runs out of file descriptors, don't go to
infinite loop (unlikely to have happened unless the OS's default
fd limit was too low)
- Fixed non-plaintext password lookups from LDAP. Patch by Lior Okman
- %U modifier was actually lowercasing the string. Patch by Ben Winslow(06.04.12 kl.11:08) Timo Sirainen skrev följande till dovecot@dovecot.org:
- Killing dovecot master process now kills all IMAP and POP3 processes also.
Does this mean I cannot upgrade dovecot on my production server without all currently logged on users being thrown out? If so they wont like it :-). Could this be configurable ?
Thanks for the great software, Jens
'Old C programmers don't die ... they're just cast into void*' Jens Låås Email: jens.laas@data.slu.se
Department of Computer Services, SLU Phone: +46 18 67 35 15
Vindbrovägen 1
P.O. Box 7079
S-750 07 Uppsala
SWEDENSeconded! I was happy with killing the master process and then doing "pkill imap; pkill pop3" if I wanted to kill off the sessions too. Also what happens if the master process dies (e.g. runs out file descriptors)? Before, it could be restarted.
Best Wishes, Chris
Jens Laas wrote:
(06.04.12 kl.11:08) Timo Sirainen skrev följande till dovecot@dovecot.org:
* Killing dovecot master process now kills all IMAP and POP3 processes also.Does this mean I cannot upgrade dovecot on my production server without all currently logged on users being thrown out? If so they wont like it :-). Could this be configurable ?
Thanks for the great software, Jens
'Old C programmers don't die ... they're just cast into void*'
Jens Låås Email: jens.laas@data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrovägen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Where were you when everyone said they wanted them killed and no-one but me supported the old behavior? ;) Guess I'll make it configurable. Or maybe alternative kill signal, eg. SIGINT?
Although the reason why I figured that maybe it's a good idea to kill them anyway is because after master is killed, the processes can no longer log anything because all logging went through master.
On Wed, 2006-04-12 at 10:41 +0100, Chris Wakelin wrote:
Seconded! I was happy with killing the master process and then doing "pkill imap; pkill pop3" if I wanted to kill off the sessions too. Also what happens if the master process dies (e.g. runs out file descriptors)? Before, it could be restarted.
Best Wishes, Chris
Jens Laas wrote:
(06.04.12 kl.11:08) Timo Sirainen skrev följande till dovecot@dovecot.org:
* Killing dovecot master process now kills all IMAP and POP3 processes also.Does this mean I cannot upgrade dovecot on my production server without all currently logged on users being thrown out? If so they wont like it :-). Could this be configurable ?
Thanks for the great software, Jens
'Old C programmers don't die ... they're just cast into void*'
Jens Låås Email: jens.laas@data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrovägen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN
Sorry! I should have said something (particularly as I'm on the CVS mailing list so could see you changed it). I'd realised about the logging, but that's a small price to pay for being able to upgrade on-the-fly.
Perhaps an alternative is to have some way to signal the master process to re-exec itself when its binary has been replaced. Sounds tricky though, especially as would need to grab all the open pipes somehow.
Failing that, an alternative kill signal sounds like the way to go.
Best Wishes, Chris
Timo Sirainen wrote:
Where were you when everyone said they wanted them killed and no-one but me supported the old behavior? ;) Guess I'll make it configurable. Or maybe alternative kill signal, eg. SIGINT?
Although the reason why I figured that maybe it's a good idea to kill them anyway is because after master is killed, the processes can no longer log anything because all logging went through master.
On Wed, 2006-04-12 at 10:41 +0100, Chris Wakelin wrote:
Seconded! I was happy with killing the master process and then doing "pkill imap; pkill pop3" if I wanted to kill off the sessions too. Also what happens if the master process dies (e.g. runs out file descriptors)? Before, it could be restarted.
Best Wishes, Chris
Jens Laas wrote:
(06.04.12 kl.11:08) Timo Sirainen skrev följande till dovecot@dovecot.org:
* Killing dovecot master process now kills all IMAP and POP3 processes also.Does this mean I cannot upgrade dovecot on my production server without all currently logged on users being thrown out? If so they wont like it :-). Could this be configurable ?
Thanks for the great software, Jens
'Old C programmers don't die ... they're just cast into void*'
Jens Låås Email: jens.laas@data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrovägen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Am 12.04.2006 um 11:37 Uhr +0100 schrieb Chris Wakelin:
I'd realised about the logging, but that's a small price to pay for being able to upgrade on-the-fly.
I see it the other way round...
Having processes running on old code around after a binary upgrade strikes me as extremely icky. This, and the inability to log can make debugging so much more "interesting", and even create a security issue.
Kill 'em all, says I. ;)
hauke-- /~\ The ASCII Ribbon Campaign Hauke Fath \ / No HTML/RTF in email Institut für Nachrichtentechnik X No Word docs in email TU Darmstadt / \ Respect for open standards Ruf +49-6151-16-3281
Perhaps an alternative is to have some way to signal the master process to re-exec itself when its binary has been replaced. Sounds tricky though, especially as would need to grab all the open pipes somehow.
IIRC, doing an exec, passes all fd's to the new process, which /should/ include pipes I think. But that's just something I picked up from using some other software, and it's been a long time since I coded C, so don't quote me! ;-)
Still, having old code running sounds a little dodgy...
Tim
Linux Counter user #273956
Timothy White wrote:
IIRC, doing an exec, passes all fd's to the new process, which /should/ include pipes I think. But that's just something I picked up from using some other software, and it's been a long time since I coded C, so don't quote me! ;-)
That's true -- the hard part of having the newly exec()d process realize those fds are there, their numbers, their purpose, any associated state, etc...
It's certainly possible, but it's hard to debug if it doesn't work quite right (and leaked fds will likely go unnoticed in small quantities...)
Tim
Linux Counter user #273956
-- Ben Winslow <rain@bluecherry.net>
On Wed, 2006-04-12 at 11:37 +0100, Chris Wakelin wrote:
Sorry! I should have said something (particularly as I'm on the CVS mailing list so could see you changed it). I'd realised about the logging, but that's a small price to pay for being able to upgrade on-the-fly.
Perhaps an alternative is to have some way to signal the master process to re-exec itself when its binary has been replaced. Sounds tricky though, especially as would need to grab all the open pipes somehow.
I think that's all way too much trouble and has potential problems with leaking file descriptors. Dovecot 2.0 framework will have separate logging processes, and those could possibly live even after master has died until all log clients have died (I think it already works that way..)
Failing that, an alternative kill signal sounds like the way to go.
Now that I think of it, that won't work. The imap/pop3 processes kill themselves when they notice that the stderr pipe gets closed, so I can't think of a way for master to notify the imap/pop3 processes on-the-fly that they shouldn't die. Guess I'll add a setting instead.
Timo Sirainen wrote:
Failing that, an alternative kill signal sounds like the way to go.
Now that I think of it, that won't work. The imap/pop3 processes kill themselves when they notice that the stderr pipe gets closed, so I can't think of a way for master to notify the imap/pop3 processes on-the-fly that they shouldn't die. Guess I'll add a setting instead.
What about the alternate kill signal to the master just stopping listening for new connections? (release the *:143 and *:110 handles).
If logging by syslog you can happily have two dovecot masters sending log lines ... won't work in other cases I suppose (suppose that is what I'm missing?)
With both a new master and an old master you can then also choose to go and do a proper kill on your old master 24 hours later or something like that to ensure nothing runs on the old binaries for longer than 24 hours (as a proper kill on the master now kills all the relevant children).
Rob.
On Wed, 2006-04-12 at 21:42 +1000, Rob Middleton wrote:
What about the alternate kill signal to the master just stopping listening for new connections? (release the *:143 and *:110 handles).
If logging by syslog you can happily have two dovecot masters sending log lines ... won't work in other cases I suppose (suppose that is what I'm missing?)
With both a new master and an old master you can then also choose to go and do a proper kill on your old master 24 hours later or something like that to ensure nothing runs on the old binaries for longer than 24 hours (as a proper kill on the master now kills all the relevant children).
I guess that would work. The master itself doesn't listen for new connections, but it should just stop creating new login/auth processes. It could also kill itself automatically after all the log pipes get closed. But is it still worth it to do this? :)
On 12/04/2006 11:32 p.m., Timo Sirainen wrote:
On Wed, 2006-04-12 at 11:37 +0100, Chris Wakelin wrote:
Sorry! I should have said something (particularly as I'm on the CVS mailing list so could see you changed it). I'd realised about the logging, but that's a small price to pay for being able to upgrade on-the-fly.
Perhaps an alternative is to have some way to signal the master process to re-exec itself when its binary has been replaced. Sounds tricky though, especially as would need to grab all the open pipes somehow.
I think that's all way too much trouble and has potential problems with leaking file descriptors. Dovecot 2.0 framework will have separate logging processes, and those could possibly live even after master has died until all log clients have died (I think it already works that way..)
Failing that, an alternative kill signal sounds like the way to go.
Now that I think of it, that won't work. The imap/pop3 processes kill themselves when they notice that the stderr pipe gets closed, so I can't think of a way for master to notify the imap/pop3 processes on-the-fly that they shouldn't die. Guess I'll add a setting instead.
Note: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173048
I'm firmly of the opinion that shutting down dovecot should shut down the child processes too - but the conf option is good as at least that way there's choice (the Unix way..).
If you're doing upgrades of critical applications at times when all your users are trying to use it *and* they aren't tolerant of a minor disruption then you're probably not really doing it at the right time...and dovecot's tolerant behaviour of this is covering up what would otherwise be regarded by most in terms of network management, as an example of poor judgement.
That's why there's "scheduled downtime" and "after hours" to do these things, in case stuff goes wrong, as some users of horde with dovecot have found out lately ;)
Reuben
On Wed, 2006-04-12 at 06:51, Reuben Farrelly wrote:
That's why there's "scheduled downtime" and "after hours" to do these things, in case stuff goes wrong, as some users of horde with dovecot have found out lately ;)
What's 'after hours' for a company with users all around the world? Interesting concept, though...
Les Mikesell lesmikesell@gmail.com
On 13/04/2006 12:27 a.m., Les Mikesell wrote:
On Wed, 2006-04-12 at 06:51, Reuben Farrelly wrote:
That's why there's "scheduled downtime" and "after hours" to do these things, in case stuff goes wrong, as some users of horde with dovecot have found out lately ;)
What's 'after hours' for a company with users all around the world? Interesting concept, though...
The same time you'd do routine maintenance on other systems and networks I guess.
I'm just not sure why people want to do upgrade surgery on critical systems running on dovecot at any time, leave it in a 95% working state and hope users don't notice, whereby upgrading any other service would be done in a more controlled manner at a planned date/time with a full clean restart of the service. It only takes 10-15s to shut the child processes down and restart them, and then you know that everything is running properly on the new version.
Upgrading apache/sendmail/postfix/bind/qmail all requires a full service restart of the master and child processes, I'm not sure why there are complaints when dovecot just takes on the same behaviour.
reuben
On Thu, 2006-04-13 at 00:41 +1200, Reuben Farrelly wrote:
Upgrading apache/sendmail/postfix/bind/qmail all requires a full service restart of the master and child processes, I'm not sure why there are complaints when dovecot just takes on the same behaviour.
The difference is that IMAP connections are long living and users often get an error message when the connection dies. Web, SMTP, DNS and SMTP doesn't really have that problem unless you happen to send the request exactly at the time when the service is down.
On Wed, 2006-04-12 at 07:41, Reuben Farrelly wrote:
That's why there's "scheduled downtime" and "after hours" to do these things, in case stuff goes wrong, as some users of horde with dovecot have found out lately ;)
What's 'after hours' for a company with users all around the world? Interesting concept, though...
The same time you'd do routine maintenance on other systems and networks I guess.
For the network, the redundant backups cover it transparently.
I'm just not sure why people want to do upgrade surgery on critical systems running on dovecot at any time, leave it in a 95% working state and hope users don't notice, whereby upgrading any other service would be done in a more controlled manner at a planned date/time with a full clean restart of the service. It only takes 10-15s to shut the child processes down and restart them, and then you know that everything is running properly on the new version.
Upgrading apache/sendmail/postfix/bind/qmail all requires a full service restart of the master and child processes, I'm not sure why there are complaints when dovecot just takes on the same behaviour.
Those services are all short term connections with no state maintained. No one will notice if you restart them or even reconnect the next time to a different machine. IMAP clients get very unhappy when they lose their connection and most don't fix it transparently. Unfortunately since they don't disconnect on a regular basis it probably isn't a good idea to even try to wait for the client to finish like apache does on a graceful restart. You might as well just kill it and say 'oops...'. It might be worth some effort to let a pop connection finish, though.
-- Les Mikesell lesmikesell@gmail.com
Les Mikesell wrote:
I'm just not sure why people want to do upgrade surgery on critical systems running on dovecot at any time, leave it in a 95% working state and hope users don't notice, whereby upgrading any other service would be done in a more controlled manner at a planned date/time with a full clean restart of the service. It only takes 10-15s to shut the child processes down and restart them, and then you know that everything is running properly on the new version.
Upgrading apache/sendmail/postfix/bind/qmail all requires a full service restart of the master and child processes, I'm not sure why there are complaints when dovecot just takes on the same behaviour.
Those services are all short term connections with no state maintained. No one will notice if you restart them or even reconnect the next time to a different machine. IMAP clients get very unhappy when they lose their connection and most don't fix it transparently. Unfortunately since they don't disconnect on a regular basis it probably isn't a good idea to even try to wait for the client to finish like apache does on a graceful restart. You might as well just kill it and say 'oops...'. It might be worth some effort to let a pop connection finish, though.
I think it depends a bit on how big the upgrade was as well. If the dovecot index format hasn't changed, then you're probably OK letting older imap processes carry on for a bit (minus logging). If the indexes *have* changed then you run the risk of a second imap connection opening the same folder (e.g. to move messages) and the two versions getting into a rebuild war over the indexes.
I've been contemplating an on-the-fly upgrade from beta3 for the two issues we've seen but that most users aren't noticing: outlook-idle fix is broken and something goes wrong with our webmail when postponing a message (probably an "append" issue).
Best Wishes, Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Wed, 2006-04-12 at 17:58 +0100, Chris Wakelin wrote:
I think it depends a bit on how big the upgrade was as well. If the dovecot index format hasn't changed, then you're probably OK letting older imap processes carry on for a bit (minus logging). If the indexes *have* changed then you run the risk of a second imap connection opening the same folder (e.g. to move messages) and the two versions getting into a rebuild war over the indexes.
I don't think the index file format has changed for many months now, and I'm not planning on changing it anymore before v2.0 (at least in incompatible ways).
Fedora Core 4: http://fedora.ivazquez.net/yum/4/i386/RPMS.alternatives/dovecot-1.0-0.iva.9.... http://fedora.ivazquez.net/yum/4/i386/SRPMS.alternatives/dovecot-1.0-0.iva.9...
http://fedora.ivazquez.net/yum/4/ppc/RPMS.alternatives/dovecot-1.0-0.iva.9.b... http://fedora.ivazquez.net/yum/4/ppc/SRPMS.alternatives/dovecot-1.0-0.iva.9....
http://fedora.ivazquez.net/yum/4/x86_64/RPMS.alternatives/dovecot-1.0-0.iva.... http://fedora.ivazquez.net/yum/4/x86_64/SRPMS.alternatives/dovecot-1.0-0.iva...
Fedora Core 5: http://fedora.ivazquez.net/yum/5/i386/RPMS.alternatives/dovecot-1.0-0.iva.9.... http://fedora.ivazquez.net/yum/5/i386/SRPMS.alternatives/dovecot-1.0-0.iva.9...
http://fedora.ivazquez.net/yum/5/ppc/RPMS.alternatives/dovecot-1.0-0.iva.9.b... http://fedora.ivazquez.net/yum/5/ppc/SRPMS.alternatives/dovecot-1.0-0.iva.9....
http://fedora.ivazquez.net/yum/5/x86_64/RPMS.alternatives/dovecot-1.0-0.iva.... http://fedora.ivazquez.net/yum/5/x86_64/SRPMS.alternatives/dovecot-1.0-0.iva...
-- Ignacio Vazquez-Abrams <ivazquez@ivazquez.net> http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
# Keep the mailbox locked for the entire POP3 session. pop3_lock_session = yes
This doesn't seem to work yet. (linux, dovecot beta 7 with default locking)
I can telnet to the server, login and then hit it with a normal pop3 client and I'm still able to download mail. I'd expect to see an error message "Mailbox locked, Is another session active?"
Ken Pacific.Net
Timo Sirainen wrote:
Fixes, mostly:
- The login and master usernames were reversed when using master_user_separator (now the order is UW-IMAP compatible).
- Killing dovecot master process now kills all IMAP and POP3 processes also.
- -a parameter to dovecot prints now all settings that Dovecot uses. -n prints all settings that are different from defaults.
- Added pop3_lock_session setting
- %M modifier returns string's MD5 sum. Patch by Ben Winslow
- PLAIN SASL authentication wasn't working properly, causing failed logins with some clients (broken in beta4)
- Fixes to Maildir++ quota, should actually work now
- Don't crash if passwd-file has entries without passwords (eg. deny=yes databases)
- Fixed prefetch userdb to work nicely with other userdbs
- If master process runs out of file descriptors, don't go to infinite loop (unlikely to have happened unless the OS's default fd limit was too low)
- Fixed non-plaintext password lookups from LDAP. Patch by Lior Okman
- %U modifier was actually lowercasing the string. Patch by Ben Winslow
On Apr 13, 2006, at 2:42 AM, Ken A wrote:
# Keep the mailbox locked for the entire POP3 session. pop3_lock_session = yes
This doesn't seem to work yet. (linux, dovecot beta 7 with default locking)
Looks like I forgot one part of the code: Index: src/master/mail-process.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/mail-process.c,v retrieving revision 1.88 diff -u -r1.88 mail-process.c --- src/master/mail-process.c 12 Apr 2006 19:40:23 -0000 1.88 +++ src/master/mail-process.c 13 Apr 2006 00:54:28 -0000 @@ -241,6 +241,8 @@ env_put("POP3_REUSE_XUIDL=1"); if (set->pop3_enable_last) env_put("POP3_ENABLE_LAST=1"); + if (set->pop3_lock_session) + env_put("POP3_LOCK_SESSION=1"); if (set->mbox_dirty_syncs) env_put("MBOX_DIRTY_SYNCS=1"); if (set->mbox_very_dirty_syncs)
I can telnet to the server, login and then hit it with a normal pop3 client and I'm still able to download mail. I'd expect to see an error message "Mailbox locked, Is another session active?"
Currently it just waits a couple of minutes for the lock and then gives some error message.
Thanks! That fixed the session lock issue. Ken Anderson Pacific.Net Timo Sirainen wrote:
On Apr 13, 2006, at 2:42 AM, Ken A wrote:
# Keep the mailbox locked for the entire POP3 session. pop3_lock_session = yes
This doesn't seem to work yet. (linux, dovecot beta 7 with default locking)
Looks like I forgot one part of the code:
Index: src/master/mail-process.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/mail-process.c,v retrieving revision 1.88 diff -u -r1.88 mail-process.c --- src/master/mail-process.c 12 Apr 2006 19:40:23 -0000 1.88 +++ src/master/mail-process.c 13 Apr 2006 00:54:28 -0000 @@ -241,6 +241,8 @@ env_put("POP3_REUSE_XUIDL=1"); if (set->pop3_enable_last) env_put("POP3_ENABLE_LAST=1"); + if (set->pop3_lock_session) + env_put("POP3_LOCK_SESSION=1"); if (set->mbox_dirty_syncs) env_put("MBOX_DIRTY_SYNCS=1"); if (set->mbox_very_dirty_syncs)
I can telnet to the server, login and then hit it with a normal pop3 client and I'm still able to download mail. I'd expect to see an error message "Mailbox locked, Is another session active?"
Currently it just waits a couple of minutes for the lock and then gives some error message.
Dovecot's pop server with pop3_lock_session = yes will wait 5 min, by default (lock_timeout = 300) and then say "-ERR No INBOX for user." I think the error message should come back sooner and say something more appropriate, like "-ERR Mailbox is locked. Is another session active?". The error message is easy to change in src/pop3/client.c. The problem then is that the mailbox file may not exist if this is a new user. I also found that dovecot will create a directory if no mbox file exists yet. This causes "Internal error occurred" messages in the log, since the mbox should be a plain file, not a directory. I might have something wrong in my dovecot.conf file that is causing this though. Here's my "default_mail_env" line: default_mail_env = mbox:/var/spool/mail/%n:INBOX=/var/spool/mail/%n:INDEX=/dovecot_indexes/%n Any ideas? Thanks, Ken A Pacific.Net Timo Sirainen wrote:
On Apr 13, 2006, at 2:42 AM, Ken A wrote:
# Keep the mailbox locked for the entire POP3 session. pop3_lock_session = yes
This doesn't seem to work yet. (linux, dovecot beta 7 with default locking)
Looks like I forgot one part of the code:
Index: src/master/mail-process.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/mail-process.c,v retrieving revision 1.88 diff -u -r1.88 mail-process.c --- src/master/mail-process.c 12 Apr 2006 19:40:23 -0000 1.88 +++ src/master/mail-process.c 13 Apr 2006 00:54:28 -0000 @@ -241,6 +241,8 @@ env_put("POP3_REUSE_XUIDL=1"); if (set->pop3_enable_last) env_put("POP3_ENABLE_LAST=1"); + if (set->pop3_lock_session) + env_put("POP3_LOCK_SESSION=1"); if (set->mbox_dirty_syncs) env_put("MBOX_DIRTY_SYNCS=1"); if (set->mbox_very_dirty_syncs)
I can telnet to the server, login and then hit it with a normal pop3 client and I'm still able to download mail. I'd expect to see an error message "Mailbox locked, Is another session active?"
Currently it just waits a couple of minutes for the lock and then gives some error message.
Answering my own questions here, but for anyone else who's running Dovecot as a pop3/pop3s only server, with simple /var/spool/mail/mbox files, and no user home directories, here is a setup that works: default_mail_env = mbox:/var/dovecot/%n:INBOX=/var/spool/mail/%n:INDEX=/var/dovecot/%n This seems a little counter-intuitive, but it works. The pop3 locking error can be modified in src/pop3/client.c to be more appropriate. The error can be made conditional on the type of lock/storage error returned, but I'm not much of a C programmer, so I won't post my code for that! :-) The lock timeout can be changed to 15 sec in the dovecot.conf so that pop locks don't cause 5 minute waits for users. Ken A Pacific.Net Ken A wrote:
Dovecot's pop server with pop3_lock_session = yes will wait 5 min, by default (lock_timeout = 300) and then say "-ERR No INBOX for user."
I think the error message should come back sooner and say something more appropriate, like "-ERR Mailbox is locked. Is another session active?". The error message is easy to change in src/pop3/client.c. The problem then is that the mailbox file may not exist if this is a new user.
I also found that dovecot will create a directory if no mbox file exists yet. This causes "Internal error occurred" messages in the log, since the mbox should be a plain file, not a directory.
I might have something wrong in my dovecot.conf file that is causing this though. Here's my "default_mail_env" line:
default_mail_env = mbox:/var/spool/mail/%n:INBOX=/var/spool/mail/%n:INDEX=/dovecot_indexes/%n
Any ideas?
Thanks, Ken A Pacific.Net
Timo Sirainen wrote:
On Apr 13, 2006, at 2:42 AM, Ken A wrote:
# Keep the mailbox locked for the entire POP3 session. pop3_lock_session = yes
This doesn't seem to work yet. (linux, dovecot beta 7 with default locking)
Looks like I forgot one part of the code:
Index: src/master/mail-process.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/master/mail-process.c,v retrieving revision 1.88 diff -u -r1.88 mail-process.c --- src/master/mail-process.c 12 Apr 2006 19:40:23 -0000 1.88 +++ src/master/mail-process.c 13 Apr 2006 00:54:28 -0000 @@ -241,6 +241,8 @@ env_put("POP3_REUSE_XUIDL=1"); if (set->pop3_enable_last) env_put("POP3_ENABLE_LAST=1"); + if (set->pop3_lock_session) + env_put("POP3_LOCK_SESSION=1"); if (set->mbox_dirty_syncs) env_put("MBOX_DIRTY_SYNCS=1"); if (set->mbox_very_dirty_syncs)
I can telnet to the server, login and then hit it with a normal pop3 client and I'm still able to download mail. I'd expect to see an error message "Mailbox locked, Is another session active?"
Currently it just waits a couple of minutes for the lock and then gives some error message.
participants (11)
-
Ben Winslow
-
Chris Wakelin
-
Hauke Fath
-
Ignacio Vazquez-Abrams
-
Jens Laas
-
Ken A
-
Les Mikesell
-
Reuben Farrelly
-
Rob Middleton
-
Timo Sirainen
-
Timothy White