[Dovecot] dovecot-1.0_rc7 crashes (Login process died too early) with repeated deletes from thunderbird
I can consistently reproduce a crash in dovecot: Select 20 or more messages and copy them to a test folder. Go into that test folder and SHIFT-DEL the messages rapidly (holding down SHIFT-DEL works best)
Just rapidly DELing them (even holding down DEL) doesn't do it (unless it's the Trash folder)
I'm using the following namespace (in case that's relevant)
namespace private { separator = . prefix = INBOX. inbox = yes }
The /var/log/syslog for the session reads: Aug 24 14:58:54 hostname dovecot: Dovecot v1.0.rc7 starting up Aug 24 14:58:55 hostname slapd[7243]: conn=147 fd=9 ACCEPT from IP=127.0.0.1:41074 (IP=0.0.0.0:389) Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 BIND dn="" method=128 Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 RESULT tag=97 err=0 text= Aug 24 14:59:09 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:09 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:09 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:09 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:09 hostname dovecot: auth(default): master in: REQUEST^I1^I10081^I1 Aug 24 14:59:09 hostname dovecot: auth(default): master out: USER^I1^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/username Aug 24 14:59:09 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:10 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:10 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:10 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:10 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:10 hostname dovecot: auth(default): master in: REQUEST^I2^I10082^I1 Aug 24 14:59:10 hostname dovecot: auth(default): master out: USER^I2^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/username Aug 24 14:59:10 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:12 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:12 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:12 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:12 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:12 hostname dovecot: auth(default): master in: REQUEST^I3^I10085^I1 Aug 24 14:59:12 hostname dovecot: auth(default): master out: USER^I3^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/username Aug 24 14:59:12 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname dovecot: IMAP(username): Disconnected Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname last message repeated 2 times Aug 24 14:59:14 hostname dovecot: Login process died too early - shutting down Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname slapd[7243]: conn=147 op=1 UNBIND Aug 24 14:59:14 hostname slapd[7243]: conn=147 fd=9 closed
--
Regards, Tim Schafer
I had the exact problem yesterday. I am using the exact same namespace. I just figured it was my email client, KMail, and my solution was to delete 10 mails at a time... I wanted to delete 142 emails at once, I highlighted all of them, shift-delete and was not able to complete the delete action... KMail crashed, if I remember correctly so I did not check the syslog of the server.
On Thursday 24 August 2006 18:18, Tim Schafer wrote:
I can consistently reproduce a crash in dovecot: Select 20 or more messages and copy them to a test folder. Go into that test folder and SHIFT-DEL the messages rapidly (holding down SHIFT-DEL works best)
Just rapidly DELing them (even holding down DEL) doesn't do it (unless it's the Trash folder)
I'm using the following namespace (in case that's relevant)
namespace private { separator = . prefix = INBOX. inbox = yes }
The /var/log/syslog for the session reads: Aug 24 14:58:54 hostname dovecot: Dovecot v1.0.rc7 starting up Aug 24 14:58:55 hostname slapd[7243]: conn=147 fd=9 ACCEPT from IP=127.0.0.1:41074 (IP=0.0.0.0:389) Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 BIND dn="" method=128 Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 RESULT tag=97 err=0 text= Aug 24 14:59:09 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:09 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:09 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:09 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:09 hostname dovecot: auth(default): master in: REQUEST^I1^I10081^I1 Aug 24 14:59:09 hostname dovecot: auth(default): master out: USER^I1^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/user name Aug 24 14:59:09 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:10 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:10 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:10 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:10 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:10 hostname dovecot: auth(default): master in: REQUEST^I2^I10082^I1 Aug 24 14:59:10 hostname dovecot: auth(default): master out: USER^I2^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/user name Aug 24 14:59:10 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:12 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:12 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:12 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:12 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:12 hostname dovecot: auth(default): master in: REQUEST^I3^I10085^I1 Aug 24 14:59:12 hostname dovecot: auth(default): master out: USER^I3^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/user name Aug 24 14:59:12 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname dovecot: IMAP(username): Disconnected Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname last message repeated 2 times Aug 24 14:59:14 hostname dovecot: Login process died too early - shutting down Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname slapd[7243]: conn=147 op=1 UNBIND Aug 24 14:59:14 hostname slapd[7243]: conn=147 fd=9 closed
Actually, it's deleting them one at a time (rapidly) that does it for me. Selecting a large group and DEL or SHIFT-DEL doesn't reproduce the problem for me.
Regards, Tim Schafer
Jim Horner said the following on 8/24/2006 3:27 PM:
I had the exact problem yesterday. I am using the exact same namespace. I just figured it was my email client, KMail, and my solution was to delete 10 mails at a time... I wanted to delete 142 emails at once, I highlighted all of them, shift-delete and was not able to complete the delete action... KMail crashed, if I remember correctly so I did not check the syslog of the server.
On Thursday 24 August 2006 18:18, Tim Schafer wrote:
I can consistently reproduce a crash in dovecot: Select 20 or more messages and copy them to a test folder. Go into that test folder and SHIFT-DEL the messages rapidly (holding down SHIFT-DEL works best)
Just rapidly DELing them (even holding down DEL) doesn't do it (unless it's the Trash folder)
I'm using the following namespace (in case that's relevant)
namespace private { separator = . prefix = INBOX. inbox = yes }
The /var/log/syslog for the session reads: Aug 24 14:58:54 hostname dovecot: Dovecot v1.0.rc7 starting up Aug 24 14:58:55 hostname slapd[7243]: conn=147 fd=9 ACCEPT from IP=127.0.0.1:41074 (IP=0.0.0.0:389) Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 BIND dn="" method=128 Aug 24 14:58:55 hostname slapd[7243]: conn=147 op=0 RESULT tag=97 err=0 text= Aug 24 14:59:09 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:09 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:09 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:09 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:09 hostname dovecot: auth(default): master in: REQUEST^I1^I10081^I1 Aug 24 14:59:09 hostname dovecot: auth(default): master out: USER^I1^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/user name Aug 24 14:59:09 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:10 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:10 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:10 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:10 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:10 hostname dovecot: auth(default): master in: REQUEST^I2^I10082^I1 Aug 24 14:59:10 hostname dovecot: auth(default): master out: USER^I2^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/user name Aug 24 14:59:10 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:12 hostname dovecot: auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Ilip=192.168.0.7^Irip=192.168.0.100 Aug 24 14:59:12 hostname dovecot: auth(default): client out: CONT^I1^I Aug 24 14:59:12 hostname dovecot: auth(default): client in: CONT^I1^IAHRdfmkerjejfkdeie Aug 24 14:59:12 hostname dovecot: auth(default): client out: OK^I1^Iuser=username Aug 24 14:59:12 hostname dovecot: auth(default): master in: REQUEST^I3^I10085^I1 Aug 24 14:59:12 hostname dovecot: auth(default): master out: USER^I3^Iusername^Isystem_user=username^Iuid=1000^Igid=100^Ihome=/home/user name Aug 24 14:59:12 hostname dovecot: imap-login: Login: user=<username>, method=plain, rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname dovecot: IMAP(username): Disconnected Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname last message repeated 2 times Aug 24 14:59:14 hostname dovecot: Login process died too early - shutting down Aug 24 14:59:14 hostname dovecot: imap-login: Disconnected: rip=192.168.0.100, lip=192.168.0.7 Aug 24 14:59:14 hostname slapd[7243]: conn=147 op=1 UNBIND Aug 24 14:59:14 hostname slapd[7243]: conn=147 fd=9 closed
The dovecot server crash is a real bug that I can confirm, but not the same as the KMail bug.
Here is what I see in my log about 15 minutes after a crash with pissed customers calling:
dovecot: Aug 25 07:07:03 Error: login: tried to change state 2 -> 2 (if you can't login at all, see src/lib/fdpass.c) dovecot: Aug 25 07:16:50 Error: login: tried to change state 2 -> 2 (if you can't login at all, see src/lib/fdpass.c) dovecot: Aug 25 15:32:59 Error: imap-login: file ioloop.c: line 22 (io_add): assertion failed: (fd >= 0) dovecot: Aug 25 15:32:59 Error: child 9903 (login) killed with signal 6 dovecot: Aug 25 15:45:19 Error: login: tried to change state 2 -> 1 (if you can't login at all, see src/lib/fdpass.c) dovecot: Aug 25 15:45:21 Error: Login process died too early - shutting down
Whatever the old 1.0 prereleases were before the RC's, they worked well for us. We have been using rc2 for a few weeks, but it spawned a huge number of pop3-login processes over time that didn't die, and we saw imap connectivity timeouts in Squirrelmail, Outlook, and Outlook Express. We then upgraded to rc6, and still saw the timeouts. We then upgraded to rc7, and now we are still seeing the timeouts, plus it's crashing from time to time.
I've put this in my crontab for now:
- if [ $(psa | grep /usr/sbin/dovecot | grep -v grep | wc -l) -lt 1 ]; then /etc/init.d/dovecot restart; fi
I'll be changing the service to run under daemontools, which will restart it within a couple seconds, soon. But please do try to get things back to the stability and performance level of the pre-RC 1.0 releases before putting out yet another broken RC. This is getting ridiculous.
What is the "best" 1.0 prerelease, as far as stability and lack of timeouts goes? I would like to roll back to that without all the guesswork.
On Thu, August 24, 2006 3:27 pm, Jim Horner wrote:
I had the exact problem yesterday. I am using the exact same namespace. I just figured it was my email client, KMail, and my solution was to delete 10 mails at a time... I wanted to delete 142 emails at once, I highlighted all of them, shift-delete and was not able to complete the delete action... KMail crashed, if I remember correctly so I did not check the syslog of the server.
That's actually a KMail bug in the latest release. It's not there in 3.5.3 if you wish to downgrade.
Cheers,
Casey Allen Shobe SeattleServer Mailing Lists lists@seattleserver.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
On 8/25/06 SeattleServer Mailing Lists wrote:
But please do try to get things back to the stability and performance level of the pre-RC 1.0 releases before putting out yet another broken RC. This is getting ridiculous.
Er, this *is* a prerelease ... of a quite excellent product, with a great community, and a responsive team ... but not production-bulletproof.
'Ridiculous' may be using it in production ... no?
/"
\ / ASCII Ribbon Campaign
X against HTML email, vCards
/ \ & micro$oft attachments
[GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iEYEAREDAAYFAkTvLKMACgkQlffdvTZxCMZxtACfTAo/Pw+lNeTmC/BhfyUlRxxM mz8An05gkwlZjKWCr/ju6hpPEuqjKbqZ =6KrL -----END PGP SIGNATURE-----
On Fri, August 25, 2006 10:00 am, Richard wrote:
Er, this *is* a prerelease ... of a quite excellent product, with a great community, and a responsive team ... but not production-bulletproof.
0.99 is crap in comparison and I believe the author said not to use it in favor of the 1.0 prereleases which were better.
'Ridiculous' may be using it in production ... no?
Well it's better than uw-imap. ;-) We've been using it in production for over a year - these problems are pretty recent.
Just hoping they clear up before too long.
-- SeattleServer Mailing Lists lists@seattleserver.com
On August 25, 2006 9:54:09 AM -0700 SeattleServer Mailing Lists lists@seattleserver.com wrote: ...
Whatever the old 1.0 prereleases were before the RC's, they worked well for us. ... I'll be changing the service to run under daemontools, which will restart it within a couple seconds, soon. But please do try to get things back to the stability and performance level of the pre-RC 1.0 releases before putting out yet another broken RC. This is getting ridiculous.
Ridiculous? What's ridiculous is using a product that's free, which is revenuing generating for you, chastising the authors for its issues, when you obviously suffer from poor production rollout processes.
You should be chastising your staff (or maybe yourself), not the dovecot authors.
I'm using b8. Like you said it works well.
-frank
Whatever the old 1.0 prereleases were before the RC's, they worked well for us. ... I'll be changing the service to run under daemontools, which will restart it within a couple seconds, soon. But please do try to get things back to the stability and performance level of the pre-RC 1.0 releases before putting out yet another broken RC. This is getting ridiculous.
Ridiculous? What's ridiculous is using a product that's free, which is revenuing generating for you, chastising the authors for its issues, when you obviously suffer from poor production rollout processes.
Ditto...
You should be chastising your staff (or maybe yourself), not the dovecot authors.
Too many people are not willing to take responsibility for their actions
- this is the primary problem in the world today.
Dovecot just rocks - occasional problems and all!!
--
Best regards,
Charles
Whatever the old 1.0 prereleases were before the RC's, they worked well for us. ... I'll be changing the service to run under daemontools, which will restart it within a couple seconds, soon. But please do try to get things back to the stability and performance level of the pre-RC 1.0 releases before putting out yet another broken RC. This is getting ridiculous.
Ridiculous? What's ridiculous is using a product that's free, which is revenuing generating for you, chastising the authors for its issues, when you obviously suffer from poor production rollout processes.
Ditto...
Ditto... but to suggest to our bitch of a user... if your using it in Production Envirnment where you have paying customers then stick to ONE known working release and let them only install the Release version when you have tested it on a test machine. Once this is done upgrade to your production machine.
You are obviously a frustrated man and perhaps need to get laid. Or am I just stooping to your level by my rude comment? :) Oh well. ITs entertaining at least. :) Peace Love and Open Source Hearts.
love, matt
On Sat, August 26, 2006 8:50 am, Matt wrote:
Ditto... but to suggest to our bitch of a user... if your using it in Production Envirnment where you have paying customers then stick to ONE known working release and let them only install the Release version when you have tested it on a test machine. Once this is done upgrade to your production machine.
You are obviously a frustrated man and perhaps need to get laid. Or am I just stooping to your level by my rude comment? :) Oh well. ITs entertaining at least. :) Peace Love and Open Source Hearts.
Except that I never made any insults to anyone. I simply stated that there have been problems associated with every RC I have tried, and they should be more stable with each release as Dovecot is working towards a 1.0 release. To have more stability problems as 1.0 grows near is not a good thing.
And I asked simply what the best version was to use, without asking for your immature retorts.
We do test new releases before deploying in production, however we don't generally notice issues such as the ones mentioned until hundreds of users are hitting the systems at once.
For one who proclaims peace and love, you really are being a hippocrite here...
Cheers,
SeattleServer Mailing Lists lists@seattleserver.com
participants (7)
-
Charles Marcus
-
Frank Cusack
-
Jim Horner
-
Matt
-
Richard
-
SeattleServer Mailing Lists
-
Tim Schafer