This is with kmail/akonadi 5.5 (17.04). After running kmail for a few hours, the Gmail account stops working. Folders are not synced anymore and messages are not displayed. I'm using two different Gmail accounts, in case it makes any difference. Akonadi terminal output: ![SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token !org.kde.pim.kimap: sasl_client_step failed with: -1 "SASL(0): successful result: " user=*user*(redacted)auth=Bearer*hash*(redacted)Pass a valid window to KWallet::Wallet::openWallet(). qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection org.kde.pim.kimap: Connection to server lost 0 org.kde.pim.imapresource: Session login cancelled [SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token ![SASL-XOAUTH2] - filling prompts ![SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token !org.kde.pim.kimap: sasl_client_step failed with: -1 "SASL(0): successful result: " user=**user2**(redacted)auth=Bearer**hash**(redacted)Pass a valid window to KWallet::Wallet::openWallet(). qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection org.kde.pim.kimap: Connection to server lost 0 org.kde.pim.imapresource: Session login cancelled org.kde.kgapi: Unauthorized. Access token has expired or is invalid. KGAPI2::EventFetchJob(0x10898a0) "Autenticación no válida." org.kde.kgapi: Unauthorized. Access token has expired or is invalid. KGAPI2::ContactsGroupFetchJob(0x24d1940) "Autenticación no válida." org.kde.pim.akonadicore: Deleting items from the akonadi database failed: "No items found" org.kde.pim.akonadicore: Error during ItemSync: "Failed to parse stream" CalendarFetchJob::url() QUrl("https://www.googleapis.com/calendar/v3/users/me/calendarList") org.kde.pim.akonadicore: Received response with a different tag! QIODevice::write (KTcpSocket): device not open Pass a valid window to KWallet::Wallet::openWallet(). [SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token ![SASL-XOAUTH2] - filling prompts ![SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token ![SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token ![SASL-XOAUTH2] - filling prompts ![SASL-XOAUTH2] - Requesting authID![SASL-XOAUTH2] - Requesting token !org.kde.pim.akonadicore: Got a stale 'changed' notification for an item which was already removed. 2137 "" org.kde.pim.akonadicore: Got a stale 'changed' notification for an item which was already removed. 2137 ""
The token should be automatically refreshed when it expires. I wonder if the problem could be that we share the same API keys with the other Google resource (calendars and contacts) and they might be "stealing" the tokens from each other...will look into it.
I've switched one of the accounts to the imap.googlemail.com domain to bypass OAUTH authentication and can't reproduce it anymore, so this seems indeed related to having two accounts.
Created attachment 106108 [details] Akonadi log I have same problem with 2 gmail accounts. Another problem with gmail accounts is that gmail resources everytime freeze when wake up from suspend to RAM. I don't know if this is related to this problem. Workaround is to restart akonadi. Attached logs from akonadi.
Can confirm that with single gmail account, but with various other google resource (calendar, addressbook), email always stop working/synching after this message: qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection org.kde.pim.kimap: Connection to server lost 0 org.kde.pim.imapresource: Session login cancelled Switching imap server to imap.googlemail.com solve the problem.
I'm having the same problem with one mail and one google contacts resource. Also no syncing after resuming from suspend.
I too have similar issues; might be different of course. Since debian/sid upgrade moved kde applications from 16.xx to 17.08, kmail has became nearly unusable, and by all accounts a burden for the user and for the cpu. I've got two gmail accounts. My computer never goes to sleep of any sort, so anything related to that is excluded here. Issues were/are: - emails not syncing for both the 2 gmail accounts - necessity to "akonadictl restart" every time I want to read my emails - when kmail is trying, uncucessfully, to retrieve those emails, it often happens, might be always but not sure, that it comes with a high cpu usage due to kwin_x11 and Xorg, the former displaying a usage of 20-30%, and the later of half that value. Today, with no reason I can see, the problems went one step ahead: after a long time left alone, I found my computer puffing and panting. Checking what was the matter with it, I found that something "akonadi" was using 115% cpu, and other things related were also using lots of cpu, like mysqld(?). Anyway, no less that three akonadictl restarts and two reboots, have been required to cool it down. Computer almost froze due to the burden. So I decided to follow the workaround of Antonio Rojas 2017-04-28 21:42:40 UTC, and changed one of one of the accounts to imap.googlemail.com. After some hiccup and one reboot, I had that working. The modified account seems to work very well, seems much faster. It doesn't seem I have those kwin/xorg high cpu usage any more. I'm not sure the unmodified account is syncing well, but it might be that it is; it's a little early to say, I've done the change only a couple of hours ago. Previously my akonadi output was showing similar error messages as described here. It doesn't seem it is any longer so. Apologies for not providing better quality information. Also, current version is 17.12: it might be that those issues are already fixed. I don't have, for the moment, access to that version of kde applications.
Update: Top output: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1427 chris 20 0 3337884 149788 72728 S 33.4 1.9 16:24.42 kwin_x11 1039 root 20 0 812388 395616 346176 S 11.3 5.0 6:44.02 Xorg 13033 chris 20 0 1287260 94980 57704 S 5.0 1.2 0:11.79 chromium 1570 chris 20 0 6535512 258840 149752 S 4.6 3.3 11:15.18 kmail 13439 chris 20 0 1380788 149636 68532 S 2.6 1.9 0:04.69 chromium Akonadi output: Pass a valid window to KWallet::Wallet::openWallet(). qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection org.kde.pim.kimap: Connection to server lost 0 org.kde.pim.imapresource: Session login cancelled Unchanged account not syncing. (that is, still using imap.gmail.com). Top output after akonadictl restart: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13033 chris 20 0 1287260 94980 57704 S 6.6 1.2 0:18.67 chromium 12935 chris 20 0 1343792 199092 106292 S 3.6 2.5 0:29.62 chromium 1427 chris 20 0 3337864 150336 72632 S 2.0 1.9 17:07.35 kwin_x11 12980 chris 20 0 890992 188400 124308 S 2.0 2.4 0:12.01 chromium 1039 root 20 0 813428 396468 346084 S 1.7 5.0 6:58.30 Xorg I'll try to change the second account to imap.googlemail.com and keep you informed. Note: I do not use Kontact, and I don't know that I use anything else related to Kmail but Kmail itself. I've got 4 accounts in Kmail, of which two are gmail's.
The reason for the 115% cpu usage described above, might be the following: 1 security issue found on your account XXXXX@gmail.com We’ve upgraded the Security Checkup to give you specific, personalized recommendations to strengthen the security of your Google Account. Take the 2-minute checkup today to see the actions you should take to make your account more secure. It might be that action, taken on the google side, that has triggered, the really troublesome issues on my computer. The timing, the time at which the "alert" has been sent, it totally relevant.
I have only a single gmail account, and I experience exactly the same issue with KMail 5.7.3 and Akonadi 17.12.3. The workaround with imap.googlemail.com works. Moreover: when using OAUTH, after selecting "serverside subscriptions", no folders show up. When using password authentication, folders do appear. Any progress in investigating this? It's a KMail showstopper for for users with GMAIL accounts (if they don't know about the workaround).
As of 18.04 the OAUTH authentication with Gmail is optional (although selected by default) and token refreshing is improved massively, so this should no longer be a problem. Feel free to reopen if you have expiration issues even on 18.04.