By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1533 - Kmail IMAP stuck after suspend
Summary: Kmail IMAP stuck after suspend
Status: NEW
Alias: None
Product: TDE
Classification: Unclassified
Component: tdepim (show other bugs)
Version: R14.0.x [Trinity]
Hardware: All Linux
: P5 minor
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 2968
  Show dependency tree / graph
 
Reported: 2013-05-29 21:29 CDT by Kris
Modified: 2018-08-30 02:52 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kris 2013-05-29 21:29:21 CDT 
This is confirmed on both R14 and 3.5.13.1 using Debian Squeeze & Wheezy, Arch, and CentOS.

I have Kmail setup with IMAPS, and set to auto-check my email every 5 minutes. After suspend to RAM, Kmail will attempt to check my email, however it sets at 0%. Kmail itself doesn't freeze, nor does it give any errors, it just holds at 0% until I cancel.

I am able to cancel the email check, and then manually (and successfully) execute an email check. Subsequent auto-checks work fine, until the next suspend to RAM when the error recurs.
Comment 1 deloptes 2016-02-21 17:46:24 CST 
I can also add to this problems with IMAP connections from Kontact.
My mail provider restarts the dovecot server each night and after this when autocheck runs it shows status -1.
The only solution for me is shutdown and start Kontact.
I always wanted to have a look into this part of the code and try find out why.
Comment 2 deloptes 2017-12-09 19:51:39 CST 
Same also after suspend and without provider restarting imap server