Kmail doesn't exit after hitting File->quit. Prior to restart, this process has to be killed by sending SIGTERM to the process. Otherwise it is not possible to start Kmail again. Occasionally that leaves the Akonadi database in an odd state (PimItemTable has entries with remoteId = NULL). At least occasionally this leads to loss of emails - which may bee seen as a secondary effect due to the disgraceful exit via SIGTERM signal. Reproducible: Always Steps to Reproduce: 1. Run Kmail 2. Execute File->quit 3. Inspect process table (e.g. with ps command) Actual Results: Kmail process found running and needs to be killed by sending SIGTERM. Expected Results: No Kmail process left after File->quit . Akonadi uses external MySQL (/usr/sbin/mysqld) as backend.
Thank you for your report, Christoph. I see this with KDEPIM compiled from master with Akonadi started MariaDB as backend since quite a while as well. That means that the process keeps running. I am not sure whether it can cause data loss or whether this the remoteId = NULL is a different, probably unrelated bug. I think I have seen at least one bug report about the remoteId = NULL thing here.
I retried (SIGTERMinating and restarting Kmail) a few times and watched PimItemTable via phpMyAdmin. Creation of entries with remoteId = NULL is not reproducible, unlike the continuation of the Kmail process. Therefore it may be unrelated indeed. Using phpMyAdmin I also looked up the date and Mail folder (aka collection name) of these spurious entries, but I couldn't remember a missing mail with that date and mail folder. So I am not sure whether I am loosing mails.
Today I scratched all Kmail2 and Akonadi config and data files in $HOME/.config and $HOME/.local/share - to no avail. The process keeps running after closing the kmail2 GUI. I haven't seen any Email losses for a while now. So the email losses I saw earlier seem to be unrelated to this bug. I made one observation though - I have ticked the option to scratch emails in trash when closing. The emails are *not* discarded. Means the process hangs somewhere before erasing trash mails.
Another observation (and work around) - unchecking the button "Settings -> Configure KMail -> Misc -> Folders -> Empty local trash folder on program exit" makes the effect disappear - the kmail process terminates gracefully. Looks like the "Empty local trash folder on program exit" is the culprit or closely related to it.
Fixed in 5.3.0