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

[George Kiagiadakis]

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


Your logic sounds sane. Perhaps it is startkde that should stop drkonqi. And one hour may be too much, actually. I'd say 15 minutes is more than enough to act. That is, if you are able to act... I've seen for example kwin crashing on logout and the screen being completely black for some minutes until I decide to switch to a tty to inspect the situation and find out that drkonqi has been launched by kwin, stopped kwin internally and everything being frozen because of that.

The best idea would be to wait no more than one minute (or even 30 seconds) and then instruct drkonqi over dbus to *save* the backtrace somewhere and then exit. This could be acompanied by some nice message in the drkonqi window (just in case it is visible) and some nice dialog popping up on the next login to report the saved backtrace. I've had this idea for a long time, but never implemented it because it needed a lot of internal changes in drkonqi to be able to use the bug reporting dialog using a saved backtrace file as input. Of course, it could be done in steps (first implement the logic to save the bt and exit, later implement the dialogs...); it would still be better than the current situation.

- George Kiagiadakis


On Dec. 10, 2012, 8:16 a.m., Jekyll Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107657/
> -----------------------------------------------------------
> 
> (Updated Dec. 10, 2012, 8:16 a.m.)
> 
> 
> 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/3bbf3fd8/attachment.htm>