Bug 76872 - IMAP disconnects and cannot reconnect
Summary: IMAP disconnects and cannot reconnect
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: IMAP (show other bugs)
Version: 1.6.1
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-06 09:36 UTC by Jens
Modified: 2008-09-10 19:15 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens 2004-03-06 09:36:22 UTC
Version:           1.6.1 (using KDE 3.2 BRANCH >= 20040204,  (testing/unstable))
Compiler:          gcc version 3.3.3 20040125 (prerelease) (Debian)
OS:          Linux (i686) release 2.6.2-bk4-jb-k7

Hi,

I have an IMAP account with courier-imap on the server. The IMAP server shuts down for maintenance each night, so the connection is lost. But I keep KMail running all the time (in the panel), with an IMAPS connection.

Each morning when I get back to my computer I see a popup window "Connection to imap.spamfreemail.de is broken" (translated back from German). I click OK, but neither "Fetch new mail" nor F5 in some folder will actually reconnect.

"Fetch new mail" just sits there, saying "Account spamfreemail.de is being searched for new mails" and doesn'T even display a progress bar at the bottom right. F5 doesn't do anything.

Restarting KMail doesn't help. Killing all kio_imap4 processes produces a couple error messages but after that I can again read my mail. (even without restarting KMail)


So this might actually be more kio_imap4 related than KMail related but I couldn't find kio_imap4 in the packages list of the bugreport tool =;)


Thank you!

Jens
Comment 1 Carsten Burghardt 2004-07-08 21:21:49 UTC
This is fixed in kdepim HEAD
Comment 2 Gav Wood 2005-01-21 12:31:25 UTC
*still* exhibits this behaviour in 3.4beta

this bug has been around forever.

gav
Comment 3 Gav Wood 2005-01-21 12:42:07 UTC
on a slightly more in depth check of this bug, apparently explicitly click the abort button will actually reset the connection and allow the user to continue to use kmail.

the bug still stands, but at least there's an easy workaround now (easier than killing kio_newimap).

gav
Comment 4 Tom Albers 2005-01-21 12:53:48 UTC
We have made some changes to fix this recently. Please check with KDE3.4, when it arrives. And please be a bit more friendly to our developers. They do a fantastic job I think.
Comment 5 Tom Albers 2005-01-21 12:57:51 UTC
hmm. This should be fixed in beta 1, in the other report you indicate you are using that. Hence reopen.
Comment 6 Carsten Burghardt 2005-01-22 15:49:24 UTC
I just tested exactly this case and kmail reconnects correctly. Can you describe what you did?
Comment 7 Jens 2005-01-24 08:55:01 UTC
Hi Carsten,

if you were adressing me: I don't have a choice to try 3.4beta1 currently (I'm using KMail at work and can't install beta software), but I could provide a test account on spamfreemail.de (as this is my domain). Please tell me if this would help.

Thanks,

Jens
Comment 8 Michael Kreitzer 2005-03-24 05:13:26 UTC
I have been getting this behavior for as long as I can remember.  From at least kde 3.2 up to kde 3.4, and I've had over that period accounts at two different providers.  Most of the time using the abort button does nothing.  Actually, the abort button doesn't seem to ever work for anything, but that's another bug for another day I suppose.  If I am lucky just killing the offending kio_imap4 process will cause kmail to work again.  Most of the time, however, I must exit kmail, kill the kio_imap4 process, and start kmail back up.  Usually I just leave kmail running overnight or while I am at work and come home to find it in this state always accompanied by the disconnection error dialog.
Comment 9 Jens 2005-03-24 12:12:30 UTC
Hello,

I'm using 3.4.0 now, SuSE 9.1 and 9.2.
I don't have the "kio_newimap must be killed" problem any more, restarting KMail usually works. But I still have a problem reconnecting to IMAP servers. Sometimes my INBOX (IMAP online, not disconnected) just becomes empty and I havee to switch to another mailbox and then back to make it reappear. But this does not work all of the time.

One of my IMAP accounts can only be reached by a SSH tunnel, over a slightly unreliable link. Sometimes the SSH connection breaks down. When that happens, KMail complains it cannot reach "localhost" (correct) but it simply doesn't retry after I click on OK. I have to restart KMail after re-starting 'ssh -L ...' every time this happens.

Again, if you need a test account, or any other kind of help, please tell me. I've been trying to reproduce and trigger this bug (among others) for over a year now but I still cannot _exactly_ specify a set of instructions to make it appear 100%.

Thanks!

Jens
Comment 10 Rich Birch 2005-03-24 12:34:09 UTC
I just tried to reproduce this by bringing my internet connection down 
while kmail was open and checking my (connected) imap account each 
minute. I got a message telling me the connection was broken and then an 
unknown host message. I left it maybe 15 mins before bringing my 
connection up again, and then everying worked ok again.

Thinking about it I guess this isn't the same situation as some of the 
others have described since my public ip stays constant across the 
disconnect/reconnect.

At first guess I'd say there is an error code being overlooked from a 
KIO::Slave::slaveError signal in ImapAccountBase::handleError. But I've 
looked through KIO::Slave's possible error codes and I haven't seen one 
that was missing in the handleError function (apart from 
KIO::ERR_UNKNOWN_HOST which I've added but haven't submitted a patch for 
yet).

I could be wrong about this but that seems like an obvious place for 
this bug residing.
Comment 11 Jens 2005-03-24 13:02:17 UTC
Would it help if I compiled KMail with debug info and used it until it triggers the bug? Or is this a race that can't be fixed even with debug info?
Comment 12 Jens 2005-03-24 13:07:56 UTC
I have a scenario here right now that might be connected to this. I have two IMAP accounts: on the one that connects directly, the IMAP server is quite slow. Right now, when I switch from the other account to this one, the INBOX shows 117 messages but none are displayed in the message list!

Also, the statusbar just says "[time] Transfer für mailbox (other mailbox) finished, no new messages". I can press F5 all I want, the kio_imap4 job that is connected to the slow IMAP server just sits there and does nothing (according to strace).

If I close kontact, the kio_imap4 job does this:

read(3, "   970_50_", 10)               = 10
read(3, "\0\0\0\1\0\0\0\34\0s\0s\0l\0_\0s\0e\0s\0s\0i\0o\0n\0_"..., 2416) = 2416
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "     4_4d_", 10)               = 10
read(3, "\0\0\0N", 4)                   = 4
write(6, "\27\3\1\0\32\22\303=\273\265l\23\262\26v8\357\265\246\341"..., 31) = 31
select(7, [6], NULL, NULL, {0, 0})      = 0 (Timeout)
time(NULL)                              = 1111665896
select(7, [6], NULL, NULL, {60, 0})     = 1 (in [6], left {59, 978000})
read(6, "\27\3\1\0\'", 5)               = 5
read(6, "[\'\217%l\17\334\246\346\263X\1\312\365=9\200\366\275\342"..., 39) = 39
write(3, "     0_68_", 10)              = 10
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "     0_32_", 10)               = 10
write(6, "\27\3\1\0\34\354\201\270\17H7\210\0\271\217\371w\344k\361"..., 33) = 33
select(7, [6], NULL, NULL, {0, 0})      = 0 (Timeout)
time(NULL)                              = 1111665956
select(7, [6], NULL, NULL, {60, 0})     = 1 (in [6], left {59, 930000})
read(6, "\27\3\1\0R", 5)                = 5
read(6, "T\213G\301^\224\365\256+\327\313A%g\303Wb\321K\27\26c\270"..., 82) = 82
write(6, "\25\3\1\0\22,\36\224\362\242\360L\f\254H(\0048\271\10\277"..., 23) = 23
close(6)                                = 0
munmap(0x41937000, 4096)                = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "", 10)                         = 0
close(3)                                = 0
close(3)                                = -1 EBADF (Bad file descriptor)
munmap(0x41936000, 4096)                = 0
ioctl(4, FIONREAD, [1])                 = 0
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
setsockopt(3, SOL_IPV6, 26, [0], 4)     = -1 EOPNOTSUPP (Operation not supported)
connect(3, {sa_family=AF_UNIX, path="/tmp/ksocket-jens/klauncherQPUQGb.slave-socket"}, 49) = 0
fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x41936000
_llseek(3, 0, 0xbfffea50, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "     0_33_", 10)               = 10
getpid()                                = 5770
write(3, "    24_6d_\0\0\26\212\0\0\0\5imap\0\0\0\0\22\0l\0o\0"..., 46) = 46

and eventually exits.

Is there a socket timeout or something in there somewhere that kio_imap4 does not catch?

Thanks! :)

Jens
Comment 13 Rich Birch 2005-03-24 13:40:22 UTC
Jens,

You may be on to something here. There is a KIO::ERR_SERVER_TIMEOUT 
error code which is not dealt with in the kmail imap code. Whether or 
not this code ever gets sent to kmail is, to me at least, uncertain. 
Unfortunately the debug output won't tell you which error code kmail has 
received, but I can change that if someone can apply a patch for me.

If we could get some more debug output in cvs would you be able to 
compile from cvs and try it? I don't currently have cvs write access but 
I'll do my best to get someone to commit a patch for me.

On a more general note, this issue may be fixed, for some people, by 
including the check for KIO::ERR_UNKNOWN_HOST in handleError(). If the 
imap server is offline when kmail checks mail then it may well get an 
unknown host error from KIO::Slave, which is currently not explicitly 
dealt with.

Thoughts?
Comment 14 Michael Kreitzer 2005-04-19 23:35:20 UTC
I've discovered new behavior which may be helpful.  I was actually on my PC for once when I got disconnected, and I was able to hit the OK button on the dialog immediately.  After doing so, to my complete surprise, kmail reconnected just fine and went on like normal.  The kio_imap4 process only seems to hang if the lost connection dialog isn't dealt with quickly.  If the dialog stays there for several hours before hitting OK then I get the behavior described in this bug.  Perhaps while the io slave is waiting on the user to acknowledge the error something else is happening that it isn't taking into account?
Comment 15 Carsten Burghardt 2005-05-10 22:30:24 UTC
Fixed for cvs HEAD
Comment 16 Daniel 2007-09-29 23:23:31 UTC
Using KDE 3.5.7 (KMail 1.9.7) from Debian unstable, and experiencing this problem. Exactly what Michael Kreitzer described actually. If I leave the "IMAP server disconnected" popup window hanging there for several hours, then KMail is unable to reconnect. I have to kill `pkill kio_imap4`.
Comment 17 p92 2007-10-23 11:09:58 UTC
I still have this problem with kmail 4:3.5.7enterprise20070926-0ubuntu2 in kubuntu gutsy  - 
KMail Version 1.9.6 (enterprise 0.20070907.709405) 
 
Comment 18 Daniel 2007-10-23 15:55:06 UTC
Yepp, still there with 3.5.8... Honestly, I'm kinda getting used to it :) Perhaps this won't be fixed, and we should just wait for 4.0? ;)
Comment 19 p92 2008-01-29 09:07:37 UTC
and yes, it is reproducible if you do a suspend to disk and then start again after a certain time (certainly equivalent to receiving a connection reset on the imap socket)

the problem is :
- kmail cannot read the inbox again
- kmail can read any other folder again

the problem is only related to imap inbox ... weird
Comment 20 Harald Sitter 2008-09-10 14:26:03 UTC
It would be very cool if you could actually reopen the bug if you think it is not fixed :-P

Does this issue still appear in 4.1.1?
Comment 21 Thomas McGuire 2008-09-10 19:15:55 UTC
The suspend/resume thing mentioned in comment 19 is in bug 77862 already, so let's not reopen this bug report.