This is fixed in kdepim HEAD

*still* exhibits this behaviour in 3.4beta

this bug has been around forever.

gav

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

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.

hmm. This should be fixed in beta 1, in the other report you indicate you are using that. Hence reopen.

I just tested exactly this case and kmail reconnects correctly. Can you describe what you did?

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

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.

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

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.

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?

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

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?

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?

Fixed for cvs HEAD

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`.

I still have this problem with kmail 4:3.5.7enterprise20070926-0ubuntu2 in kubuntu gutsy  - 
KMail Version 1.9.6 (enterprise 0.20070907.709405) 
 

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? ;)

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

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?

The suspend/resume thing mentioned in comment 19 is in bug 77862 already, so let's not reopen this bug report.