[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Causes of session management problems in Plasma 5
From: Henry Miller <hank () millerfarm ! com>
Date: 2015-11-24 2:31:30
Message-ID: 5C5B7BD6-DAD9-4E15-9E24-56638D0CB9D7 () millerfarm ! com
[Download RAW message or body]
I'll object to no interaction after logout. More than once I've asked "why is logout \
taking so long, Jumped to a terminal (not always konsole) to look.
Also, on Windows (at least) a running terminal application will block logout so I \
may need to kill the application while in a logout context. I'm not sure how this \
relates to konsole on other platforms, but it seems like the use case exists.
On November 23, 2015 7:02:46 PM CST, Andreas Hartmetz <ahartmetz@gmail.com> wrote:
> Hello,
>
> As apparently one of the last users of session management, because I
> shut down my computers about once every day, I run into problems about
> as often as I log into a session that is supposed to be restored.
> The number one problem is Konsole just not restoring.
> So I took some time to investigate the problem. The result is that
> there
> are several bugs that conspire to break session restore. It goes about
> like this:
>
> - ksmserver (the session manager) sends clients the "SaveYourself"
> message and collects the responses. This works fine.
> - In Qt applications, this results in a call to
> QGuiApplicationPrivate::commitData(), which calls
> QApplicationPrivate::tryCloseAllWindows() after the part that sends
> the SaveYourselfDone response to the session manager.
> When QGuiApplication::quitOnLastWindowClosed() is true (the default),
> this results in the application quitting.
> - ksmserver notices that (e.g.) konsole has terminated and purges it
> from its internal data
> - ksmserver rounds up remaining processes, which at this point do not
> include konsole, and saves their restore data. konsole thus has saved
> its state, but ksmserver forgot about it and doesn't remember to do
> anything with konsole when restoring the session later.
>
> The two most obvious errors are thus:
>
> - QGuiApplicationPrivate::commitData() calling
> QApplicationPrivate::tryCloseAllWindows(), together with
> QGuiApplication::quitOnLastWindowClosed() being true by default. Quote
> from documentation of signal QGuiApplication::commitDataRequest():
> "You should not exit the application within this signal. Instead, the
> session manager may or may not do this afterwards, depending on the
> context."
> Note that it says session manager and afterwards, not QGuiApplication
> and virtually immediately.
>
> - The session manager not "locking down" or better copying the list of
> clients *while* logging out. This would arguably only help buggy
> clients, but may still be a net positive.
> Why copy the list? Logout may be canceled, so it is valuable to keep
> the main client list updated for after logout cancellation.
>
> - Bonus: I've found that KMainWindowPrivate::init() calls
> QCoreApplication::setQuitLockEnabled(true), which is equivalent to
> QGuiApplication::setQuitOnLastWindowClosed(true), which is either
> redundant with the default or overrides something the user has
> explicitly changed. I noticed this while trying to narrow down the
> problem with a call to
> QGuiApplication::setQuitOnLastWindowClosed(false) from konsole's
> Application class. Which is not a good solution, but sufficient as a
> proof of concept fix. That fix works as far as session save and
> restore are concerned.
>
> So now I wonder what the chances are to fix those bugs.
>
> - Make ksmserver more robust in the face of clients dying too early,
> sure. I hope to get around to it Soon(TM).
>
> - Remove QCoreApplication::setQuitLockEnabled(true) from
> KMainWindowPrivate::init() - seems like a good idea to me, objections?
>
> - Remove any window closing from QGuiApplicationPrivate::commitData() -
> this is actually an old feature that was even modified in 2014 to
> fix a problem on Windows(?!) - I guess that one is there to prevent
> interaction after session saving, but it's a very crude way to do
> that. IMO it would be better to do nothing, it would be even better
> to block user input and possibly I/O handling for the duration of
> logout and unblock them when logout is canceled.
> Note: the Windows fix is about the method being expected to *kill*
> the application, which probably comes from a lack of knowledge about X
> session management which is the main purpose of that method. Commit
> 9835a63dde06a1e5d2f in qtbase.
>
> I'd be grateful for any additional insight and / or historical
> perspective.
>
> Cheers,
> Andreas
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[Attachment #3 (text/html)]
<html><head></head><body>I'll object to no interaction after logout. More than \
once I've asked "why is logout taking so long, Jumped to a terminal (not \
always konsole) to look.<br> <br>
Also, on Windows (at least) a running terminal application will block logout so I \
may need to kill the application while in a logout context. I'm not sure how \
this relates to konsole on other platforms, but it seems like the use case exists. \
<br><br><div class="gmail_quote">On November 23, 2015 7:02:46 PM CST, Andreas \
Hartmetz <ahartmetz@gmail.com> wrote:<blockquote class="gmail_quote" \
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); \
padding-left: 1ex;"> <pre class="k9mail">Hello,<br /><br />As apparently one of the \
last users of session management, because I <br />shut down my computers about once \
every day, I run into problems about <br />as often as I log into a session that is \
supposed to be restored.<br />The number one problem is Konsole just not \
restoring.<br />So I took some time to investigate the problem. The result is that \
there <br />are several bugs that conspire to break session restore. It goes about \
<br />like this:<br /><br />- ksmserver (the session manager) sends clients the \
"SaveYourself" <br /> message and collects the responses. This works fine.<br />- In \
Qt applications, this results in a call to <br /> \
QGuiApplicationPrivate::commitData(), which calls <br /> \
QApplicationPrivate::tryCloseAllWindows() after the part that sends<br /> the \
SaveYourselfDone response to the session manager.<br /> When \
QGuiApplication::quitOnLastWindowClosed() is true (the default),<br /> this results \
in the application quitting.<br />- ksmserver notices that (e.g.) konsole has \
terminated and purges it<br /> from its internal data<br />- ksmserver rounds up
remaining processes, which at this point do not <br /> include
konsole, and saves their restore data. konsole thus has saved <br />
its state, but ksmserver forgot about it and doesn't remember to do<br
/> anything with konsole when restoring the session later.<br /><br
/>The two most obvious errors are thus:<br /><br />-
QGuiApplicationPrivate::commitData() calling <br />
QApplicationPrivate::tryCloseAllWindows(), together with<br />
QGuiApplication::quitOnLastWindowClosed() being true by default. Quote
<br /> from documentation of signal
QGuiApplication::commitDataRequest():<br /> "You should not exit the
application within this signal. Instead, the<br /> session manager may
or may not do this afterwards, depending on the<br /> context."<br />
Note that it says session manager and afterwards, not
QGuiApplication<br /> and virtually
immediately.<br /><br />- The session manager not "locking down" or
better copying the list of<br /> clients *while* logging out. This
would arguably only help buggy<br /> clients, but may still be a net
positive.<br /> Why copy the list? Logout may be canceled, so it is
valuable to keep<br /> the main client list updated for after logout
cancellation.<br /><br />- Bonus: I've found that
KMainWindowPrivate::init() calls <br />
QCoreApplication::setQuitLockEnabled(true), which is equivalent to<br
/> QGuiApplication::setQuitOnLastWindowClosed(true), which is
either<br /> redundant with the default or overrides something the
user has<br /> explicitly changed. I noticed this while trying to
narrow down the <br /> problem with a call to <br />
QGuiApplication::setQuitOnLastWindowClosed(false) from konsole's<br />
Application class. Which is not a good solution, but sufficient as a<br
/> proof of concept fix. That fix works as far as session save and <br
/> restore are
concerned.<br /><br />So now I wonder what the chances are to fix those
bugs.<br /><br />- Make ksmserver more robust in the face of clients
dying too early,<br /> sure. I hope to get around to it Soon(TM).<br
/><br />- Remove QCoreApplication::setQuitLockEnabled(true) from <br />
KMainWindowPrivate::init() - seems like a good idea to me,
objections?<br /><br />- Remove any window closing from
QGuiApplicationPrivate::commitData() -<br /> this is actually an old
feature that was even modified in 2014 to<br /> fix a problem on
Windows(?!) - I guess that one is there to prevent <br /> interaction
after session saving, but it's a very crude way to do <br /> that. IMO
it would be better to do nothing, it would be even better <br /> to
block user input and possibly I/O handling for the duration of <br />
logout and unblock them when logout is canceled.<br /> Note: the
Windows fix is about the method being expected to *kill*<br /> the
application, which probably comes from a lack
of knowledge about X<br /> session management which is the main purpose of that \
method. Commit<br /> 9835a63dde06a1e5d2f in qtbase.<br /><br />I'd be grateful for \
any additional insight and / or historical <br />perspective.<br /><br />Cheers,<br \
/>Andreas<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic