Summary: | Akonadi is utterly broken for an IMAP account since 5.8.2 | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Martin Ottmar <mirovski36> |
Component: | IMAP resource | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | cherkaba, dvratil, gtdev |
Priority: | NOR | ||
Version: | 5.8.2 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
annoying windows
network traffic generated when akonadi is running |
Description
Martin Ottmar
2018-07-16 15:35:01 UTC
Created attachment 113969 [details]
network traffic generated when akonadi is running
I'm unable to find anything about this broken IMAP resource logged in akonadi console logs. There are plenty of messages from other IMAP resources and from CALDAV resource. Almost two months without my favorite IMAP account. :-O Akonadi has been "fixed" by adding iptables permanent DROP rule for OUTPUT packets to the broken IMAP server. It "fixes" everything strange meant above, except the IMAP account itself, of course, which behaves as disconnected now. So, akonadi and the KDE workspace are usable together again. Volny.cz does support STARTTLS, so your communication was secured the whole time :) But it looks like volny.cz only supports PLAIN authentication method, while it looks like we are trying to log in with LOGIN authentication method (or at least I assume that "Metoda 'Příhlášení' selhala" is just a bad translation for the "LOGIN" method). Please check in the IMAP account's settings (in the Advanced) tab whether the "Authentication" method selected is "PLAIN" (I hope this is not localized :)). I'm pretty sure, I've tried all three interesting methods ("Čistý text", "PLAIN" and "LOGIN") for all encryption methods (None, SSL/TLS and STARTTLS). And the PLAIN method was the preferred one. No any combination is working now, with the new akonadi 18.08/5.9.0 (Good news everyone, the google account is broken now! :-D ). I looks like any combination I choose is ignored completely, and it uses the same default with the same result. BTW: What is the difference between methods "Čistý text" and "PLAIN", if any? If I try to set STARTTLS/PLAIN (None/PLAIN / STARTTLS/PLAIN) and then I drop the mentioned iptables output rule, and to renew the incoming manually, the follow mouse policy method makes the desktop unusable, and the network traffic skyrockets immediately. Sometimes, within this hell, I'm able to see the strange window mentioned above for a moment, but it disappears immediately. The following is from the akonadi console: Job ID Created Wait Time Job Duration Job Type State Info akonadi_imap_resource_1 19538 15:20:25 CEST.935 00:00:00.014 Custom-startConnect Running 19541 15:20:25 CEST.964 00:00:00.007 Custom-startConnect Running 19544 15:20:25 CEST.987 00:00:00.009 Custom-startConnect Running 19547 15:20:26 CEST.009 00:00:00.008 Custom-startConnect Running 19550 15:20:26 CEST.031 00:00:00.010 Custom-startConnect Running 19553 15:20:26 CEST.054 00:00:00.009 Custom-startConnect Running 19556 15:20:26 CEST.076 00:00:00.011 Custom-startConnect Running 19559 15:20:26 CEST.100 00:00:00.011 Custom-startConnect Running 19562 15:20:26 CEST.123 00:00:00.009 Custom-startConnect Running 19565 15:20:26 CEST.144 00:00:00.014 Custom-startConnect Running 19568 15:20:26 CEST.172 00:00:00.009 Custom-startConnect Running 19571 15:20:26 CEST.197 00:00:00.012 Custom-startConnect Running 19574 15:20:26 CEST.222 00:00:00.009 Custom-startConnect Running 19577 15:20:26 CEST.244 00:00:00.010 Custom-startConnect Running 19580 15:20:26 CEST.267 00:00:00.011 Custom-startConnect Running 19583 15:20:26 CEST.291 00:00:00.012 Custom-startConnect Running 19586 15:20:26 CEST.316 00:00:00.009 Custom-startConnect Running 19589 15:20:26 CEST.338 00:00:00.010 Custom-startConnect Running 19592 15:20:26 CEST.364 00:00:00.011 Custom-startConnect Running 19595 15:20:26 CEST.389 00:00:00.009 Custom-startConnect Running 19598 15:20:26 CEST.411 00:00:00.009 Custom-startConnect Running 19601 15:20:26 CEST.432 00:00:00.009 Custom-startConnect Running 19604 15:20:26 CEST.454 00:00:00.012 Custom-startConnect Running 19607 15:20:26 CEST.479 00:00:00.012 Custom-startConnect Running 19610 15:20:26 CEST.505 00:00:00.010 Custom-startConnect Running 19613 15:20:26 CEST.528 00:00:00.011 Custom-startConnect Running 19616 15:20:26 CEST.558 00:00:00.012 Custom-startConnect Running 19619 15:20:26 CEST.590 00:00:00.012 Custom-startConnect Running 19622 15:20:26 CEST.620 00:00:00.009 Custom-startConnect Running 19625 15:20:26 CEST.646 00:00:00.010 Custom-startConnect Running 19628 15:20:26 CEST.673 00:00:00.009 Custom-startConnect Running 19631 15:20:26 CEST.695 00:00:00.012 Custom-startConnect Running 19634 15:20:26 CEST.725 00:00:00.012 Custom-startConnect Running 19637 15:20:26 CEST.751 00:00:00.014 Custom-startConnect Running 19640 15:20:26 CEST.778 00:00:00.009 Custom-startConnect Running 19643 15:20:26 CEST.801 00:00:00.009 Custom-startConnect Running 19646 15:20:26 CEST.822 00:00:00.009 Custom-startConnect Running 19649 15:20:26 CEST.844 00:00:00.011 Custom-startConnect Running 19652 15:20:26 CEST.870 00:00:00.011 Custom-startConnect Running 19655 15:20:26 CEST.893 00:00:00.011 Custom-startConnect Running 19658 15:20:26 CEST.917 00:00:00.009 Custom-startConnect Running 19661 15:20:26 CEST.939 00:00:00.010 Custom-startConnect Running 19664 15:20:26 CEST.962 00:00:00.009 Custom-startConnect Running 19667 15:20:26 CEST.985 00:00:00.009 Custom-startConnect Running I'm suddenly seeing a similar thing with a bunch of "Custom-startConnect" tasks running and all my IMAP resources failing to connect, although they cause high CPU load on themselves and the session dbus instance. This affects two servers that did not change configuration. The resources show "online, idle" with status message "ready" in akonadiconsole but flash to some other state too quickly to see ("offline" maybe). There is zero useful information anywhere, `akonadictl --verbose start` prints a lot of garbage but nothing pointing toward a problem, and akonadiconsole isn't helping either. me to i got probleme with kmail and others services since laste update: -probleme imap but not smtp - all services about wich depends on plasma-discover do not work because of https://autoconfig.kde.org/ocs/providers.xml file missing - cannot re-create googledrive account (online account) - kio error for kontact (not sure it's related on) config: debian-kde plasma 5.13.5 / kde frameworks 5.49.0 / QT 5.11.1 kernel 4.18.0-1 repo buster/testing (In reply to Cherkah from comment #7) > me to i got probleme with kmail and others services since laste update: > -probleme imap but not smtp > - all services about wich depends on plasma-discover do not work because of > https://autoconfig.kde.org/ocs/providers.xml file missing > - cannot re-create googledrive account (online account) > - kio error for kontact (not sure it's related on) > > > config: > debian-kde plasma 5.13.5 / kde frameworks 5.49.0 / QT 5.11.1 > kernel 4.18.0-1 > repo buster/testing the last update has resolved my probleme thx Just sixt months (from the first report) without my favorite email account on my desktop. Currently there is akonadi 18.12.1/5.10.1 installed. All problems reported within this ticket are still here. I don't see much progress even in other reported bugs. Is akonadi dead? I'm sorry. This has been probably fixed yet in 2019, but I've forgotten to close this. Reading IMAP accounts works fine now (still last versions with archlinux), maybe exept the unpleasant long pause after network re-connection (manual refresh doesn't work too until some timeout - expected automatic pull immediately after network re-connection). |