Version: unspecified (using KDE 4.5.0) OS: Linux ksmserver tries to shut down programs in shutdown.cpp and legacy.cpp, but big apps take a bit of time to actually close. Yes, ksmserver hard-kills them after only a few seconds. It’s not ever configurable how long. This is the reason for that well-known problem with Firefox complaining about a crashed session (with TabMixPlus. Without it, it just does not show that it crashed, but I did prove in my investigations, that it still does.) This is the case with all big apps. Notable Firefox, Thunderbird, and all bigger Java applications. (All NetBeans-based ones for example. Also Sancho.) I don’t know it it’s from the hard killing signal ksmserver then sends after the timeout, but FF and TR definitely lose data. Chanes to their session after the last automatic session saving for example. This is a critical problem. I think ksmserver should wait longer, and at the end, when there are still open apps, show a dialog, asking if they should be (something equivalent to) SIGQUIT, -TERM, or -KILLed, or if shutdown should be canceled. Reproducible: Always Steps to Reproduce: 0. (if you want details, enable full logging for ksmserver) 1. Start a new KDE session, run Firefox (with installed TabMixPlus session management automatically restoring sessions on startup), Thunderbird, Sancho, ThinkingRock (or NetBeans itself), and at least one or two other apps (like Kaffeine in my case). 2. Open tabs, work on e-mail accounts, log into a mldonkey server, browse TR projects, etc, to get some data into the apps. 3. Log out of the session. 4. Watch for Firefox to sometims be visible with no window decoration, since kwin already got exited via normal session storage. 5. Log in again. Actual Results: A. Watch Firefox start with a crashed session error. B. Watch Sancho complain about an existing lock. C. Watch the logs of ksmserver, which will show you that FF, TB and Sancho got focefully terminated. Expected Results: Firefox and other apps should be given enough time, to properly shut down, even if this takes minutes(!). Since the alternative – data loss – is not acceptable.
Git commit e648950adef6bca37c554f586b611006e041d931 by Martin Koller. Committed on 22/08/2012 at 16:49. Pushed by mkoller into branch 'KDE/4.9'. make the client shutdown timeout configurable sometimes the timeout for applications to shutdown is too short, e.g. when running on old hardware, having lots of applications open, browsers with many tabs, etc. This patch adds two config entries with which you can define the timeout before ksmserver kills the apps. In the [General] section of ksmserverrc you can define: legacySaveTimeoutSecs (default = 4 seconds) clientShutdownTimeoutSecs (default = 15 seconds; was 10 before) Related: bug 273326 FIXED-IN: 4.9.1 REVIEW: 106090 M +13 -5 ksmserver/legacy.cpp M +7 -1 ksmserver/shutdown.cpp http://commits.kde.org/kde-workspace/e648950adef6bca37c554f586b611006e041d931
Git commit 7213d2081e0bc8fb4a34f0af9f526da9380b9e95 by Martin Koller. Committed on 22/08/2012 at 16:49. Pushed by mkoller into branch 'master'. make the client shutdown timeout configurable sometimes the timeout for applications to shutdown is too short, e.g. when running on old hardware, having lots of applications open, browsers with many tabs, etc. This patch adds two config entries with which you can define the timeout before ksmserver kills the apps. In the [General] section of ksmserverrc you can define: legacySaveTimeoutSecs (default = 4 seconds) clientShutdownTimeoutSecs (default = 15 seconds; was 10 before) Related: bug 273326 FIXED-IN: 4.9.1 REVIEW: 106090 M +13 -5 ksmserver/legacy.cpp M +7 -1 ksmserver/shutdown.cpp http://commits.kde.org/kde-workspace/7213d2081e0bc8fb4a34f0af9f526da9380b9e95
We misunderstood each other. The purpose of this bug, as opposed to 273326, was that > ksmserver should wait longer [done, but not the point of this particular bug], and at the end, when there are still open apps, show a dialog, asking if they should be (something equivalent to) SIGQUIT, -TERM, or -KILLed, or if shutdown should be cancelled [not done]. So I’m re-opening this bug, since creating a new one for that, would rightfully be called a duplicate. :) Sadly, I can’t write C++. Otherwise this would be what I’d write (in pseudo-code): runningSessionProcs = … // list of all running processes in the session that we’re exiting from terminationDelay = … // the optionally configurable delay to wait after sigterm nextSignalDelay = … // the optionally configurable delay to wait after the timeout warning dialog nextSignal = null // the next thing the user chose to do with non-exiting processes for (proc in runningSessionProcs) { sendSignal(TERM,proc) } wait(terminationDelay) while (runningSessionProcs.length > 0 && nextSignal != IGNORE_AND_CONTINUE_ANYWAY) { nextSignal = timeoutWarningDialog.prompt() // User gets to choose a signal, to just wait longer, or to ignore things and continue shutting down without doing anything about those processes. if (nextSignal != IGNORE_AND_CONTINUE_ANYWAY) { if (nextSignal != null) { for (proc in runningSessionProcs) { sendSignal(nextSignal,proc) } } wait(nextSignalDelay) } }
*** This bug has been marked as a duplicate of bug 390515 ***