Review Request: Do not wait for remaining Dr.Konqi instances without timeout when ending the KDE session

Jekyll Wu adaptee at gmail.com
Mon Dec 10 08:16:22 GMT 2012


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107657/
-----------------------------------------------------------

Review request for kde-workspace and George Kiagiadakis.


Description
-------

The existing code in startkde waits for Dr.Konqi instances to finish their jobs (saving or reporting the backtrace). That is good, since it make it possible to report crashes during the logout/shutdown procedure. But waiting for Dr.Konqi without timeout is not good:

  * When users comes back to their computers hours later, they can hardly remember their working context when trying to logout/shutdown previously.  I wouldn't expect those annoyed users are willing or able to create useful report under that situation.

  * It wastes power ...


Some users suggest Dr.Konqi should implement a timeout feature, and one user even provides a patch (I tried). However, I don't think that timeout should be done within Dr.Konqi :


   * It is not that Dr.Konqi intentionally blocks the procedure. It is the opposite, where startkde itself decides to wait for Dr.Konqi and block itself. So logically, the timeout should be done in startkde, not in Dr.Konqi. 

   * If the timeout is done in Dr.Konqi, then Dr.Konqi should only enable that timeout when the system is in the logout/shutdown procedure. 

     That user provided patch clearly doesn't consider that, and the result is if something (like kded) crashes when my system is idle and I'm away, then I won't even know kded has crashed when I comes back hours later.

     And detecting "whether the system is in the produce of logout/shutdown" is tricky. It can check whether org.kde.ksmserver is still reachable, but that only applies to a KDE session. So Dr.Konqi should add extra code to check whether it is running in a KDE session , whether ksmserver has gone, and the timeout itself. That sounds unnecessary extra work.


So I propose startkde should add a timeout. The patch uses hardcoded 1 hour ( I think that is already long enough, or maybe still too long) as the timeout. Not sure whether it is worthwhile to make the timeout configurable at compile time or runtime.


The only downside is some backtrace might be lost. But I don't think that is a big deal. Crashes during shutdown are rare cases nowadays(I hope I'm right), and users noticing those crashes only hours later are the rare case in rare cases (but very annoying).  


 


This addresses bug 126073.
    http://bugs.kde.org/show_bug.cgi?id=126073


Diffs
-----

  startkde.cmake dc6f050 

Diff: http://git.reviewboard.kde.org/r/107657/diff/


Testing
-------


Thanks,

Jekyll Wu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121210/38f5cf49/attachment.htm>


More information about the kde-core-devel mailing list