[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 Martin Ottmar changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #10 from Martin Ottmar --- 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). -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 --- Comment #9 from Martin Ottmar --- 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? -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 --- Comment #8 from Cherkah --- (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 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 Cherkah changed: What|Removed |Added CC||cherifkah...@gmail.com --- Comment #7 from Cherkah --- 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 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573
Nicos Gollan changed:
What|Removed |Added
CC||gt...@spearhead.de
--- Comment #6 from Nicos Gollan ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573
--- Comment #5 from Martin Ottmar ---
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 DurationJob 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
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 Daniel Vrátil changed: What|Removed |Added CC||dvra...@kde.org --- Comment #4 from Daniel Vrátil --- 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 :)). -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 --- Comment #3 from Martin Ottmar --- 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. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 --- Comment #2 from Martin Ottmar --- 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. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 396573] Akonadi is utterly broken for an IMAP account since 5.8.2
https://bugs.kde.org/show_bug.cgi?id=396573 --- Comment #1 from Martin Ottmar --- Created attachment 113969 --> https://bugs.kde.org/attachment.cgi?id=113969=edit network traffic generated when akonadi is running -- You are receiving this mail because: You are watching all bug changes.
