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