Bug 273326

Are you implying that Firefox doesn't implement X session management correctly and we should work around it in KDE?

(In reply to comment #1)
> Are you implying that Firefox doesn't implement X session management correctly
> and we should work around it in KDE?

I do not know the internal mechanism of session management. Therefore I cannot say where the problem is.
If it is a more general problem I can post a bugreport to Firefox.
For me it seems as KDE should "simple" wait a little bit longer to let Firefox shut down properly and then close X.

> I do not know the internal mechanism of session management

Try http://www.google.com/search?q=x+session+management

> For me it seems as KDE should "simple" wait a little bit longer

The KDE session manager (ksmserver) waits for the reply from all applications that register for X session management. If Firefox indicates that all data has been committed, or if Firefox crashes and therefore closes the connection to the session manager, then ksmserver has no reason to wait any longer and will inform the login manager that the session can be terminated.

I would suggest to ask Firefox developers if the problem could be in specific plugins.

As for Java applications, I doubt that they support session management at all. I haven't seen API in Java that maps to XSM.

I am reassigning this report to ksmserver for further inspection.

Actually, (In reply to comment #3)
> The KDE session manager (ksmserver) waits for the reply from all applications
> that register for X session management.

Actually, it kills everything after a timeout of 10 seconds. (Last time I looked at the code.)
Which, in case of some big apps being open and memory swapping going on, is not enough. But of course, that doesn’t mean that it’s killed that way in my case.

Also, Firefox is considered a "legacy session management" program. Why, when it’s apparently doing proper X session management, I do not know.


> I would suggest to ask Firefox developers if the problem could be in specific
> plugins.

I did tests with all plugins disabled. One problem is, that vanilla Firefox is very good at acting as if nothing happened when it crashed. It restores its tabs. And most things you do, get saved to disk right away anyway. But it still crashes. Which can be seen by the few things that Firefox saves only at exit. (Including late changes to the periodically saved data.)

So making a small extension which saves its data only at exit, may be the best way to reproduce this.


> As for Java applications, I doubt that they support session management at all.
> I haven't seen API in Java that maps to XSM.

Well, they don’t have to. As long as they are terminated properly.
See, when I change a column width in a table in a Java program that saved those widths at exit (like Sancho or, I think, ThinkingRock), then when I use the [x] button in the window decoration, or the KDE program close shortcut (like Alt-F4 in Windows), and re-start it, the column width is kept.
When I leave the program running, exit the session, log in again, and re-start the program manually (yep, there’s no auto-start-again support), the column width is lost.

The problem seems to be, that ksmserver doesn’t seem to use the normal program close command, but something more forcefully. It may well be, that a normal SIGTERM already is that more forceful way. In that case, just changing that, would already solve the problem.

Oh, and obviously, the timeout should be configurable, as e.g. in my case, I do not *ever* want to lose data, just because ksmserver was too impatient and I happen to have more programs than usually open. :)
(I’d set it to 2 minutes here. Better safe than sorry.)

> I am reassigning this report to ksmserver for further inspection.

Thank you. If you need any info, I’m happy to help. :)

So apparently nobody at KDE cares? At all? You just murder every child that hasn’t left the class room after 10 seconds? :/

Does that mean the only solution is to patch ksmserver to a different timeout myself…? :(

But seriously… 10 seconds and no warning, no “Would you like to wait a little longer or kill them off?”? What are you thinking? Even Windows does that. And it doesn’t have any real session management at all.

subscribe

Ok, I’ve found a very reliably and easily reproducible example of how the session management fails for all cases where there are a couple of large applications open.
The steps can be found over at Gentoo’s bug tracker: https://bugs.gentoo.org/show_bug.cgi?id=364109#c8
And the results of me doing it: https://bugs.gentoo.org/show_bug.cgi?id=364109#c9
A temporary workaround, doing what KDE should be doing in the first place, manually: https://bugs.gentoo.org/show_bug.cgi?id=364109#c10

Now all you guys have to do, is implement the workaround as real code inside your own session management, and you’re good. It’s all done for you. How about that?

subscribe

*** This bug has been confirmed by popular vote. ***

ping

By the way: This is still the case. With all software based on the Mozilla platform or on Java.

Easily reproducible by simply e.g. opening any Mozilla-based program after an update, seeing its “new version” tab, closing it, logging out of KDE, logging in again, watching the program come back up with the tab still there as if it was never closed.
When doing the same but closing/opening the program manually instead of logging out/in, it works as expected and the tab stays closed.

Same thing with changing table column width in (I think any Java program, but I know it for a fact in) e.g. Sancho.

I still use my complete workaround of the KDE session management, because frankly, it is just… FAIL.

I wonder though: Does not a single of the KDE developers use Firefox or Thunderbird? I thought it was more popular.
Because if anyone would use it, it would be fixed in an hour. :(

Added a patch to make the timeout configurable here:
https://git.reviewboard.kde.org/r/106090/

(In reply to comment #12)
Awesome, Martin!

But I wonder: Would it be possible for ksmserver to ask the user if he thinks the applications are hanging and would like to kill them, or if he wants to continue to wait for another $timeout seconds?

Because that would allow one to have a short timeout and still not have everything killed outright.
And I think this functionality existed in the past…

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 248459
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 248459
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

I can imagine that sometimes it would make sense to ask the user what to do if the app does not react after a timeout.
If you think this wish shall be implemented, please open a new issue.
thanks.

(In reply to comment #16)
> I can imagine that sometimes it would make sense to ask the user what to do
> if the app does not react after a timeout.
> If you think this wish shall be implemented, please open a new issue.
> thanks.

Martin, this was the whole point and reason I filed the bug #248459 in the first place. Not to have a configurable timeout time, but to have that dialog. I quote:

> 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.

So while I appreciate there being a configurable timeout, this doesn’t solve the problem that if something surpasses the timeout… whatever it may be set to… you don’t get to decide at all, and it just outright kills it for you.

The problem with that, is that it, as it seems to happen more and more often, is treating the user like a complete idiot who doesn’t know what he’s doing, and is nothing more than meat with eyes. ;) 
In other words: The MS Clippy syndrome of the software knowing better what you want, than yourself, /without even asking you/. It’s incredibly annoying and if you’d be treated like that in every day situations, you’d feel insulted.

It’s a computer. Not an iPad. We have brains. Ask the user. :)

So while this bug here is fixed, bug #248459 still is unresolved.

This has always annoyed me too.

And to be honest, I don't think the code change made to address this bug is a fix. It is a (very welcome!) workaround.

You can't expect people to dive into the guts of KDE and add an obscure option to a hidden away configuration file to fix a problem that is so common and impacts so many people (everybody who uses Firefox and/or Thunderbird).

(In reply to comment #18)
> (everybody who uses Firefox and/or Thunderbird).

Don’t forget *all* Java applications. (As far as I know.)