Bug 86516

Summary: Stale KMail lock file produces startup problems
Product: [Unmaintained] kmail Reporter: Christopher Smith <bugzilla>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 1.6.2   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Christopher Smith 2004-08-03 20:17:46 UTC 
Version:           1.6.2 (using KDE KDE 3.2.3)
Installed from:    SuSE RPMs

Whenever KMail exits uncleanly (system crash, segfault, kill -9, whatever), it leaves behind a lockfile in ~/.kde/share/apps/kmail/lock .  Trying to start KMail if this lockfile exists currently (in release versions) brings up a big scary error message that most people don't know how to fix (just delete the listed file).  The CVS fix to bug 60753 provides an option to delete the lockfile and continue.  Most users, however, are unlikely to understand lockfiles or be able to make a good choice.  Since the lockfile includes the PID of the "current" instance of KMail, shouldn't lockOrDie *first* check to see whether there's a copy of KMail running at that PID and nuke the lockfile without user intervention if there's not?
Comment 1 Juha Tuomala 2006-02-05 10:16:33 UTC 
Related bug 112024 and bug 109637.
Comment 2 Jonathan Marten 2006-10-28 18:26:45 UTC 
KDE-PIM bugs day: cannot reproduce with kmail 1.9.5, KDE 3.5.5

To confirm: start kmail, copy ~/.kde/share/apps/kmail/lock to /tmp/lock, quit Kmail.  Copy /tmp/lock back to ~/.kde/share/apps/kmail/lock.  Run kmail, it starts up cleanly and updates the lock file with its new PID.

Existing lockfile with stale PID is now properly handled in KMail::lockOrDie() (kmstartup.cpp).