Bug 362695

Summary:	Kmail process continues running after exiting with File->quit.
Product:	[Applications] kmail2	Reporter:	Christoph Pospiech <pospiech-HD>
Component:	misc	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	critical	CC:	Martin, montel
Priority:	NOR
Version:	5.1.3
Target Milestone:	---
Platform:	Kubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	5.3.0
Sentry Crash Report:

Description Christoph Pospiech 2016-05-05 09:54:29 UTC

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.

Comment 1 Martin Steigerwald 2016-05-05 10:01:12 UTC

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.

Comment 2 Christoph Pospiech 2016-05-05 10:45:50 UTC

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.

Comment 3 Christoph Pospiech 2016-08-23 17:18:34 UTC

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.

Comment 4 Christoph Pospiech 2016-08-24 07:54:26 UTC

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.

Comment 5 Laurent Montel 2016-08-24 09:59:55 UTC

Fixed in 5.3.0