https://bugs.kde.org/show_bug.cgi?id=389829
--- Comment #14 from Raúl <rasas...@gmail.com> --- Attila, sorry for the delay in answering. I'm not a KDE developer but I can explain you what I suspect about this bug and how it can be related (if not duped) to https://bugs.kde.org/show_bug.cgi?id=434706. kontact/akonadi is a user fronted which shows data that those get from akonadi which, in turn, is closely bounded to a database. The database is made up of tables and registers. You can take a look at those tables and registers using an external database browser or the database command line client. For instance, in my case akonadi relies on mariadb database engine and I can query the akonadi data externally like this: ``` $ mariadb -S/run/user/1001/akonadi/mysql.socket MariaDB [(none)]> use akonadi; MariaDB [akonadi]> show tables ; +----------------------------------+ | Tables_in_akonadi | +----------------------------------+ | collectionattributetable | | collectionmimetyperelation | | collectionpimitemrelation | | collectiontable | | flagtable | | mimetypetable | | parttable | | parttypetable | | pimitemflagrelation | | pimitemtable | | pimitemtagrelation | | relationtable | | relationtypetable | | resourcetable | | schemaversiontable | | tagattributetable | | tagremoteidresourcerelationtable | | tagtable | | tagtypetable | +----------------------------------+ 19 rows in set (0.001 sec) ``` kontact/kmail sends database queries to feed akonadi database and also to retrieve data. I think either the query flow or the database engine has some kind of bug or limitation. Hence one of the database queries locks some database tables (like those listed above) and therefore most of the database operations are locked (they cannot be completed). https://bugs.kde.org/show_bug.cgi?id=434706 explains some similar behavior and that is why I asked you to check if both reports are about the same problem. You are right that https://bugs.kde.org/show_bug.cgi?id=434706 is too technical and this is where you could get lost. In order to check whether the problem is the same or not, here is the list of actions that you can perform to verify: * Wait for the problem to reproduce or reproduce it yourself (if possible) * Check `journalctl -xe` output and look for recent output like this: ``` kmail[1317]: org.kde.pim.akonadicore: Received response with a different tag! akonadi_maildispatcher_agent[1586]: void SendJob::setFrom(const QString &from) "m...@milianw.de" akonadi_maildispatcher_agent[1586]: d->m_returnPath "<m...@milianw.de>" akonadiserver[1305]: org.kde.pim.akonadiserver: QueryBuilder::exec(): database reported transaction deadlock, retrying transaction akonadiserver[1305]: org.kde.pim.akonadiserver: "Deadlock found when trying to get lock; try restarting transaction QMYSQL3: Unable to execute statement" akonadi_imap_resource[1583]: org.kde.pim.imapresource: "Connection to server lost." ``` * Additionally you can connect to the mariadb socket: `mariadb -S/run/user/1001/akonadi/mysql.socket` (1001 is your user code, maybe it's a different number) * Issue the following db engine query: `SHOW ENGINE INNODB STATUS` you should see that there is a deadlock detected: *LATEST DETECTED DEADLOCK* section in the https://bugs.kde.org/show_bug.cgi?id=434706 bug If you find out the same outcome, this and the other bug are quite possibly a duplicated. One additional comment is that I think the bug is not specifically about kmail, but about akonadi and its database engine usage. For getting a fix, we would need that someone with enough akonadi and DB knowledge to analyze and find out possible solutions. Unfortunately that is not by my hand. Regards, -- You are receiving this mail because: You are watching all bug changes.
