Bug 340046 - after long inactivity (sleep) mailfilter agent remains at 0% indefinitely (and kmail at "Retrieving folder contents")
Summary: after long inactivity (sleep) mailfilter agent remains at 0% indefinitely (an...
Status: RESOLVED WORKSFORME
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Mail Filter Agent (show other bugs)
Version: 1.12.91
Platform: Kubuntu Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-17 09:02 UTC by RJVB
Modified: 2022-11-29 05:17 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
output recorded after akonadictl restart (2x) (62.12 KB, text/x-log)
2014-10-17 09:04 UTC, RJVB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description RJVB 2014-10-17 09:02:52 UTC
Since upgrading to 4.14.1 and now 4.14.2 from the Kubuntu 14.04 backports PPA I experience a very annoying issue with kmail/kontact each time I wake the computer from sleep.

New mail appears to be fetched normally, but Kontact remains stuck at "Retrieving folder contents" when I select messages or change folders or even (imap) accounts. Switching it off/online does not unblock the situation, I need to restart akonadi.

After the 1st `akonadictl restart`, the situation appears to be unblocked, but the mail filter agent remains at 0% indefinitely according to both kontact's progress widget and akonadiconsole. A second akonadictl restart is required within a short laps of time in order to return things to normal. Then one can see the mail filter resource do some actual work at some point of the synchronisation process.

Given that this is on a netbook, we are by now long minutes from the moment I woke the computer from sleep.

kontact/kmail usually get in the same "Retrieving folder contents" catatonic state after having been kept offline for a while. Under 4.13.3 this was my most reliable way of preventing the "gmail too many simultaneous connections" bug by having only 1 kontact process online on 1 computer at a time.

Reproducible: Always

Steps to Reproduce:
1. Wake computer from sleep in the morning
2. Ensure it connects to the correct WLAN and enter the wallet password in the dialog posted at kontact/akonadi's request
3. Wait for sync to complete, try to read new (or even old email)


Actual Results:  
4. when it's clear kontact won't display anything else but "Retrieving folder contents",
5. do akonadictl restart
6. admire the dance in the expanded kontact progress widget and notice how the mail filter agent appears there
7. remark that said filter agent is going to remain stuck at 0% again (long) after everything else settles down (and you can actually read email)
8. do another akonadictl restart
9. as in 6, but this time the filter agent actually does things and completes its job

Expected Results:  
to be able to start handling email normally after a wake from sleep or lengthy period of having kept kontact/kmail offline.

I'm attaching a log of output obtained after entering akonadictl restart in a terminal, with debug output activated for the mail filter agent. It starts with the last output from the server processes being stopped (which look suspicious) and then shows the trace of new processes being started. It includes the output from the 2nd `akonadictl restart` required to return to normal functioning, and from what I can see it is only after that restart that output from the mail filter agent appears in the log.

It turns out that mailfilter has the same "no progress" issue when akonadi is restarted after functioning normally for a while.

A very similar issue plagues my "kdepim user experience" under OS X with kdepim 4.13.3 and akonadi 1.13.0 and (of course) a mostly identical configuration (accounts, kontact settings).

Possibly related observation: regularly email deleted from my main gmail imap account is moved not to the configured trash (on the gmail server) but to my local mail trash.
Comment 1 RJVB 2014-10-17 09:04:42 UTC
Created attachment 89172 [details]
output recorded after akonadictl restart (2x)
Comment 2 grzesiekw 2014-12-15 10:48:41 UTC
Maybe problem with mailfilter agent is related to offline folders where mails should be moved to?
I see relation with bug 331180.
Comment 3 RJVB 2014-12-15 13:04:46 UTC
Unlikely. I don't have any offline features configured (one of the reasons in fact why I'm using kmail on OS X ...)
Comment 4 dcg 2015-03-01 15:28:18 UTC
Can confirm, exactly the same symptoms here, in a POP3-only account, no offline folders. I usually do akonadictl restart and select "filter emails from this folder" manually.
Comment 5 Antonis G. 2016-01-31 13:22:58 UTC
It works if you select all your messages (Ctrl+A) and Ctrl+J
Comment 6 Frits Spieker 2017-02-05 10:27:49 UTC
This ugly bug also rears its head in Opensuse Tumbleweed.

akonadi is at version 16.12.1-1.1. As is kmail for that matter.

Sometimes restarting akonadi does seem to help but never long. I can normally read some email, but then (without any pattern that I can find) the "retrieving etc" will occupy the message pane. As far as I can tell it most of the times starts when trying to read email from a POP3 account, but when it does it will also block IMAP folders.

Any suggestions on producing usable input for debugging very welcome.
Comment 7 Justin Zobel 2022-10-30 00:37:37 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 8 Bug Janitor Service 2022-11-14 05:14:39 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Bug Janitor Service 2022-11-29 05:17:51 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!