Bug 126073 - startkde waits for remaining drkonqi instances during logout/shutdown
Summary: startkde waits for remaining drkonqi instances during logout/shutdown
Status: RESOLVED FIXED
Alias: None
Product: drkonqi
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR wishlist with 182 votes (vote)
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 141952 160970 168959 251847 261354 282389 283863 286901 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-04-22 15:33 UTC by Yevgen Muntyan
Modified: 2019-12-14 17:59 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
It adds a time out (60 secs) to drkonqi. (1.42 KB, patch)
2012-05-26 08:42 UTC, firewalker
Details
Adds 120 seconds time out with a visual down counter. (1.88 KB, patch)
2012-09-04 17:02 UTC, firewalker
Details
kwin backtrace (3.28 KB, application/octet-stream)
2013-01-16 09:16 UTC, wintonian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yevgen Muntyan 2006-04-22 15:33:29 UTC
Version:            (using KDE KDE 3.5.2)
Installed from:    Ubuntu Packages
OS:                Linux

If I am trying to shutdown kde, almost always some application crashes, usually it's kdevelop, sometimes kicker. Then drkonqi dialog shows up, and kde won't shut down until I press Close in the dialog. 
It's pretty much useless, and I am forced to remove drkonqi binary in each new kde installation. Otherwise, it's just impossible to "Select Log Out, click Turn Off Computer, and go away".
Comment 1 Shriramana Sharma 2006-07-05 14:43:46 UTC
I also have this bug with KDE 3.53 on SUSE Linux 10.1. Voting.

What should be done is:
1. The crash handler should wait for some time, say ten seconds, if it is active at system logout (which includes shutdown and reboot).
2. If the user does not respond, then it should save the crash report and a backtrace in some place, maybe ~/.drkonqui or ~/.kde/share/apps/drkonqui or something 
3. Upon next KDE login (or startup) it should bring up the same problem with the backtrace available. If the user elects not to report a bug, then this cached crash info can/should be expunged.

It is important that the backtrace is saved because obviously the backtrace will not be possible upon next startup.
Comment 2 Tim Hutt 2006-07-25 14:47:58 UTC
Yep, same problem. Usually Juk or KMail for me. What's with all these apps crashing on logout?

Anyway I agree with the comment #2. Although it might be simpler just to do the timeout for now.

Also, pressing enter doesn't work on the crash dialog - you have to use the mouse to click on 'Close'.
Comment 3 Judit Foglszinger 2006-08-21 14:45:51 UTC
I noticed this bug in kde 3.5.4 (debian testing)
but not in the older version kde 3.3.2 (debian stable).
So the reason might be a newer change in drkonqi or kde.
 
Comment 4 Guy Zelck 2007-12-26 14:00:44 UTC
Yes, same problem with app kwebilder. 
Since you're quiting kwin and X, most of your display is already wiped so you can't even see drkonqi's window. You're blocked.
Even opening a console and forcing a shutdown doesn't help. The very 1st time you encounter this you have no clue how to get out of this situation and you pull the switch on your pc with inconsistant f.s. as a result. So very, very annoying problem.
Comment 5 Diederik van der Boor 2008-06-29 15:25:07 UTC
Same here, KDE 4.1 beta 2.
Comment 6 Lubos Lunak 2008-07-09 15:56:50 UTC
*** Bug 160970 has been marked as a duplicate of this bug. ***
Comment 7 Maciej Pilichowski 2008-07-12 16:26:31 UTC
ad.#1.1) the timeout should be configurable with option "never" (never autoclose+autosave). The issue is you cannot predict what caused a crash, some data can be lost (content of the clipboard for example), the document you are looking at. I personally would rather spend some time without worrying about auto-close and find out more if I can really safely turn off computer with this crash
Comment 8 Pino Toscano 2008-10-26 15:27:50 UTC
*** Bug 168959 has been marked as a duplicate of this bug. ***
Comment 9 Jose 2008-10-26 21:50:54 UTC
I agree that there must be an option to "Never close" somewhere but I think the default behaviour should be to autoclose the dialog when the user is logging out. 
I've been using KDE for a lot time, since the KDE 3.0 days and applications crashing on exit is almost normal in KDE. It is inevitable and if you have a KDE installation for enough time there's a 99% of possibilities to have at least an application crashing on exit constantly (be it Kontact, Kopete, Klipper, whatever) which makes unattended logout impossible.
Comment 10 Ivo Anjo 2008-10-26 22:03:23 UTC
I wouldn't say that crashing is regular, but it just takes 1 app to do it, and when it happens it is *very* annoying (I'm one of those kde 4.0.0 users that today still watches for a bit if plasma will crash at shutdown, although it hasn't done so for months).

As for users that don't want the "never close": maybe a list could be added, of "apps that may crash at shutdown and we don't care". You could easily put in there things like plasma, klipper, kwin, amarok, dolphin, all kde games (... I could go on).

For the rest of them, the default could be the dialog blocks shutdown, but a message with an option could be added (even right there on the dialog):

This application has crashed and blocked the shutdown sequence. (...).
[ ] Don't let this application block shutdown again.

If the user checked that, the next time the app crashed at shutdown, it could wait some time and then autoclose drkonqi.
Comment 11 Guy Zelck 2008-10-26 22:35:10 UTC
Comment #10 holds no ground. A list of apps ..? Keep it simple.
Answering a question is often not possible because e.g. kwin's already gone and the screen is clogged up and you can't see the dialog as I already witnessed before.
Sharma's #2 comment is a good proposal.
If we want to shutdown, we don't want to be bothered with answering questions, we just want to shutdown. The backtrace for most of us is useless anyway because the apps aren't compiled with debug info.
Today we haven't got any option than to rename drkonqi so it won't bother us, which is a shame realy.
This bug is already 2,5 years old, when will someone fix this?
Maybe we can organise a get together to celebrate it's lustrum anyversary in a couple of years.
Comment 12 Ivo Anjo 2008-10-26 23:02:40 UTC
"Comment #10 holds no ground." Thanks for the constructive comment.

But I might have not explained myself right. My idea is for that list to be maintained inside drkonqi's code, of course a user shouldn't have to do a thing like that. As only kde apps use drkonqi, on that list would be many well-known kde apps that don't pose a problem if they crash on shutdown, and of course, such a list is maintained by kde developers, not users.

Also, of course it's possible to answer a question. You don't have a window manager, but you don't need that to click a checkbox, it's as hard as clicking the close button. AND, you don't have to answer the question if you don't want to AND even if you have to -- it's only once per app, how hard can that be.
Comment 13 Jose 2008-10-27 09:58:43 UTC
What's the problem with the message auto-closing? The application has crashed anyway and your data may have been lost. It's only a notification message to let you know that something bad has happened and that message could appear the next time you login to your desktop. That way you can be sure that your computer will be shut down everytime you tell it to do so. Having it blocked the first time is not a good option because in my experience every KDE will crash on exit at some point. It's a strange "feature" of KDE apps or maybe a distribution fail too but anyway, I have only seen this ratio of "crash on exit" applications in KDE so, for me, having the logout blocked by one application the first time it crashes is not a good option.
Having a list of "good crashing applications" is not possible too because you cannot control the applications that make use of the KDE framework. Look at kde-apps.org and you will find hundreds of applications that are not known to the KDE developers so, what will be the default for them? 
Comment 14 Pétur Runólfsson 2008-11-19 22:37:09 UTC
*** This bug has been confirmed by popular vote. ***
Comment 15 Dario Andres 2009-08-08 20:01:58 UTC
*** Bug 141952 has been marked as a duplicate of this bug. ***
Comment 16 Dario Andres 2009-08-08 20:27:06 UTC
Is anyone else experiencing this with KDE4.3 ?
So far, in the crash I could get here (4.4trunk) on shutdown; the DrKonqi window appears but it is closed automatically by the sessionmanager killing all the things to shutdown/close. So it does not block the shutdown.
Regards
Comment 17 Dario Andres 2009-08-08 21:14:47 UTC
In fact, the blocking mode was removed from DrKonqi.
I'm planning some changes to that behaviour so the UI will not block shutdown/logout again, but devs would be able to get/save the coredump of the crash. (if that is ever possible)
Comment 18 Ivo Anjo 2009-08-09 00:30:19 UTC
On 4.3 I can confirm that even with DrKonqi open, the session is successfully terminated.
Comment 19 Yevgen Muntyan 2009-08-13 06:56:43 UTC
So no dev has ever even looked at this thing. Good that it's fixed itself.
Comment 20 Ivo Anjo 2009-08-13 10:04:19 UTC
(In reply to comment #19)
> So no dev has ever even looked at this thing. Good that it's fixed itself.

Things just don't fix themselves: during the last round of updates to drkonqui that are in 4.3 the developers must have stumbled onto this again, and fixed it.
Comment 21 Dario Andres 2009-08-13 14:13:45 UTC
In fact, this was not a bug, but a feature added by developers to allow to fetch backtrace even on shutdown. However, we all agree that the blocking behaviour is not desirable in most of the case, so I'm looking forward a better solution to this issue.
Regards
Comment 22 Lubos Lunak 2010-06-02 17:05:01 UTC
I have fixed the problem that "it's fixed itself", so reopening.
Comment 23 Dario Andres 2010-12-10 22:16:39 UTC
*** Bug 251847 has been marked as a duplicate of this bug. ***
Comment 24 Christoph Feck 2010-12-27 15:56:48 UTC
*** Bug 261354 has been marked as a duplicate of this bug. ***
Comment 25 Dennis Schridde 2010-12-27 17:07:11 UTC
Confirming the problem in KDE 4.5.4.

My suggestion is to wait a specified amount of time for all applications to close. Afterwards kill everything that is still alive in the KDE session. This is similar to what most distributions do on shutdown with SIGTERM/SIGKILL.
Comment 26 rockachu2 2010-12-31 02:41:44 UTC
occurs on my x64 kde 4.6rc1 too.

This time its the desktop effects manager that comes with KDE (not compiz).

Its a real pain to have to sit there and click next next next close every time you want to logout.

Couldn't you make it wait 5 seconds for user input, and if not, just save the crash data and prompt on reboot?
Comment 27 Christoph Feck 2011-10-12 15:28:08 UTC
*** Bug 283863 has been marked as a duplicate of this bug. ***
Comment 28 Davide Bettio 2011-11-03 17:58:05 UTC
On Kubuntu 11.10 drkonqi might not be displayed so the screen stays black.
The only way to logout is to kill drkonqi from a terminal.
This bug must be fixed as soon as possible because it creates a bad KDE/Kubuntu user experience. Beeing able to logout or shutdown the system without any weird workaround is a requirement for every user. A good solution is to disable by default "drkonqi blocks logout" behaviour.
Comment 29 Christoph Feck 2011-11-18 11:39:44 UTC
*** Bug 286901 has been marked as a duplicate of this bug. ***
Comment 30 Stefán Freyr Stefánsson 2011-11-18 13:22:26 UTC
This is annoying the life out of me!

One other thing that annoys me on shutdown is that on my laptop, if I choose shutdown and then close the laptop, it goes into hibernation and hibernates before the shutdown completes (that is, in the few cases where nothing crashes and drkonqi isn't blocking everything). Then when I start my computer up again, it continues the shutdown and I have to turn it on again to get it up and running.

I think there needs to be some global disabling of anything that can prevent shutdown from happening after it has been selected. In the _very_ few cases where something actually needs to block the shutdown process, the programmer should have to explicitly declare that it should.
Comment 31 arne anka 2012-02-08 11:47:44 UTC
the only way i found _supposed_ to get rid of that annoyance, was to set an environment variable KDE_DEBUG.
while there's no description, what value KDE_DEBUG should have (1 or 0? true or false?), apparently the mere exsitence of that variable should stop drkonqi from starting -- which is rather counterintuitive, since the name KDE_DEBUG implies the exact opposite.
but then, the whole attempt is ... not very sensible -- a normal installation most likely has no debug packages installed, hence no usefull stacktrace will be generated ever, so the whole thing is pretty meaningless.

and on top of it, it doesn't even work.
i set that variable in a number of places and with all arguments i could imagine, but that stupid thing pops up nevertheless and blocks shutdown. 

a usefull and aptly named (well, that goes for a lot of settings i still don't really understand by their name -- and i am using kde since 1997) setting is neede to configure that behaviour in a clear and consistent manner.
Comment 32 grglsn765 2012-05-17 13:14:43 UTC
I double checked to make sure I was logging into bugs.kde.org correctly, and I was. Yet the crash reporting assistant would not let me send the back trace and report the bug when amarok crashed. Even though I copied and pasted my username and new password, it said "error invalid username or password". So that makes it pretty difficult to get the information to the crash developers.

I am using openSUSE 12.1 KDE 4.8.3
Comment 33 firewalker 2012-05-26 08:42:26 UTC
Created attachment 71377 [details]
It adds a time out (60 secs) to drkonqi.

I just inserter a time out method to quit DrKonqi after 60 seconds. You can change the value to what ever you need. The value is expressed in milliseconds (60 secs = 60000).

QTimer::singleShot(60000, qa, SLOT(quit()));
Comment 34 Aldoo 2012-06-07 11:49:12 UTC
Still an annoyance in 4.8.
Is there a good reason for not fixing this behavior, other than being low on the priority list?
Comment 35 firewalker 2012-09-04 17:02:20 UTC
Created attachment 73650 [details]
Adds 120 seconds time out with a visual down counter.

This new patch adds a visual count down timer on the close button. After 120 seconds, drkonqi will close.

http://i.imgur.com/tK7Z4.png

This patch is for version 4.9.0. Tested on ArchLinux.

P.S. I down know how to code properly in Qt. If it was possible for me it should be really trivial for the developers. I don't know why this bug is still present.
Comment 36 Jekyll Wu 2012-12-10 10:17:43 UTC
http://git.reviewboard.kde.org/r/107657/

I think the timeout should be done in startkde, not in Dr.Konqi .
Comment 37 firewalker 2012-12-10 11:28:52 UTC
My intention was to reset the timer if there was user activity present. But I got bored to go deeper on KDE code.
Comment 38 Jekyll Wu 2012-12-24 11:48:57 UTC
Git commit 011e5acd647cc5a30d2c53ed073f9aaa6f0ab12c by Jekyll Wu.
Committed on 24/12/2012 at 12:04.
Pushed by jekyllwu into branch 'master'.

Set a timeout for waiting remaning Dr.Konqi

If the timeout is reach, just ask remainging Dr.Konqis to die.
The timeout is now hardcoded as 15 minutes.
REVIEW: 107657

M  +10   -0    startkde.cmake

http://commits.kde.org/kde-workspace/011e5acd647cc5a30d2c53ed073f9aaa6f0ab12c
Comment 39 Jekyll Wu 2012-12-24 11:49:51 UTC
Git commit feac020d92bdb1993415bc0517c7c1d1d17c2963 by Jekyll Wu.
Committed on 24/12/2012 at 12:03.
Pushed by jekyllwu into branch 'KDE/4.9'.

Set a timeout for waiting remaning Dr.Konqi

If the timeout is reach, just ask remainging Dr.Konqis to die.
The timeout is now hardcoded as 15 minutes.
REVIEW: 107657

M  +10   -0    startkde.cmake

http://commits.kde.org/kde-workspace/feac020d92bdb1993415bc0517c7c1d1d17c2963
Comment 40 Jekyll Wu 2012-12-24 11:52:18 UTC
Git commit 23b5b55c04b3b8a5d755aa9893279506c269d19e by Jekyll Wu.
Committed on 24/12/2012 at 12:03.
Pushed by jekyllwu into branch 'KDE/4.10'.

Set a timeout for waiting remaning Dr.Konqi

If the timeout is reach, just ask remainging Dr.Konqis to die.
The timeout is now hardcoded as 15 minutes.
REVIEW: 107657

M  +10   -0    startkde.cmake

http://commits.kde.org/kde-workspace/23b5b55c04b3b8a5d755aa9893279506c269d19e
Comment 41 arne anka 2013-01-02 18:58:18 UTC
i am not quite sure if i understand the description correctly -- but the issue is that drkonqi _blocks_ logout.
while a crash of any application upon logout is nasty and possibly deserves research, the core issue is the failing logout/shutdown -- thus, a timeout of 15 _minutes_ waiting for any response to drkonqi is not a solution.

imo drkonqi should do nothing at all:
- usually there are no debug libs installed, hence there will be no usable stacktrace anyway
- user wants to logout/shutdown -- that's most likely not the time for prolonged waiting or activities

instead, a check for a usable stacktrace should be performed (or when possible a check for debugging facilities) -- if unavailable skip the whole drkonqi stuff. 

if necessary/desired (conf option, env var) display a short notice that something crashed (but not like some shutdown kernel messages appearing and disappearing so fast that you never can read them and only are left with the feeling of impending doom).
Comment 42 Jekyll Wu 2013-01-02 20:20:36 UTC
(In reply to comment #41)
> i am not quite sure if i understand the description correctly -- but the
> issue is that drkonqi _blocks_ logout.

No, quite the opposite. Read the review quest and the commit link,  then you will see that it was "startkde" that decided to wait fo drkonqi forever. There is no way for drkonqi itself to block the shutdown process.  "startkde" is just a shell script, not hard to read.


> while a crash of any application upon logout is nasty and possibly deserves
> research, the core issue is the failing logout/shutdown -- thus, a timeout
> of 15 _minutes_ waiting for any response to drkonqi is not a solution.

Not a real solution, but much better than the previous "waiting forever" situation. 

> 
> imo drkonqi should do nothing at all:
> - usually there are no debug libs installed, hence there will be no usable
> stacktrace anyway

No, imcomplete backtrace without debug symbols are still much more useful than no bakctrace at all.  If drkonqi just does nothing (not even showing up), then users  :

  *  maybe not even realize something has crashed during shutdown thus never report it . 
  *  cant not provide any useful infomation (backtrace, even if incomplete) except "something crashed during shutdown".
 
That make the crash less likely to be spotted, reported, investigated and fixed. 


> - user wants to logout/shutdown -- that's most likely not the time for
> prolonged waiting or activities

If he/she notice that but doesn't have time/patience at that moment, just close drkonqi with one click.  No extra time wasted for he/she. If he/she does has time/patience at that time, then why not give he/she the chance of reporting/saving the crash information ? 


> instead, a check for a usable stacktrace should be performed (or when
> possible a check for debugging facilities) -- if unavailable skip the whole
> drkonqi stuff. 

Again, that kind of smart checking should *only* happen in this special shutdown case, but not in average cases . And detecting that shutdown case (I think) is tricky and unnecessary work for drkonqi (see the review request).   The better solution is drkonqi provides more dbus methods and startkde uses them in a smarter way than now. But that might take long time to implement or never happen.
Comment 43 arne anka 2013-01-02 21:30:18 UTC
>> - user wants to logout/shutdown -- that's most likely not the time for 
>> prolonged waiting or activities 

> If he/she notice that but doesn't have time/patience at that moment, just close drkonqi with one
> click. No extra time wasted for he/she. If he/she does has time/patience at that time, then why 
> not give he/she the chance of reporting/saving the crash information ? 

what brought me here was actually that i don't want that at all. i hit ctrl+alt+del to gte the menu, hit shutdown and am on my way. if anything goes wrong upon shutdown (in kde), it doesn't concern me at this moment. hence, i don't want to see anything of this sort. just shutdown. my workaround was to remove drkonqi so i am never bothered.

thus, what i want is exactly the "smart behaviour": i don't install debug symbols for a reason and at least upon logout/shutdown under no circumstances i want to be bothered by drkonqi -- i've been using kde for about 15 years now and there was not a single instance where this kind of interruption was useful (and luckily it only happens every few years).

to put it bluntly: when i logout/shutdown i don't want to see drkonqi. period.
for all i care displaying drkonqi can be the default -- but provide a documented way to disable it.
Comment 44 Ivo Anjo 2013-01-02 22:02:07 UTC
(In reply to comment #43)
> >> - user wants to logout/shutdown -- that's most likely not the time for 
> >> prolonged waiting or activities 
> 
> > If he/she notice that but doesn't have time/patience at that moment, just close drkonqi with one
> > click. No extra time wasted for he/she. If he/she does has time/patience at that time, then why 
> > not give he/she the chance of reporting/saving the crash information ? 
> 
> what brought me here was actually that i don't want that at all. i hit
> ctrl+alt+del to gte the menu, hit shutdown and am on my way. if anything
> goes wrong upon shutdown (in kde), it doesn't concern me at this moment.
> hence, i don't want to see anything of this sort. just shutdown. my
> workaround was to remove drkonqi so i am never bothered.
> 
> thus, what i want is exactly the "smart behaviour": i don't install debug
> symbols for a reason and at least upon logout/shutdown under no
> circumstances i want to be bothered by drkonqi -- i've been using kde for
> about 15 years now and there was not a single instance where this kind of
> interruption was useful (and luckily it only happens every few years).
> 
> to put it bluntly: when i logout/shutdown i don't want to see drkonqi.
> period.
> for all i care displaying drkonqi can be the default -- but provide a
> documented way to disable it.

Indeed. Sometimes users just want to be users. If it crashed it's already too late to do something about it, so why bother the user anyway, if the user doesn't want to. Maybe some day she/he will want to contribute, but probably not during shutdown when they have other things to do.

At work, I have a fully updated kubuntu, and plasma still crashes sometimes on shutdown. Is it plasma? Is it a plasmoid? Is it a driver? I don't care. The only way it affects me is that I have to watch the shutdown to see that it completes successfully. I wish I didn't have to.
Comment 45 Dennis Schridde 2013-01-02 22:09:43 UTC
(In reply to comment #43)
> what brought me here was actually that i don't want that at all. i hit
> ctrl+alt+del to gte the menu, hit shutdown and am on my way.
+1
A 15 minute delay on shutdown is better than nothing — if it would be configurable to - say - 1 minute, it would be even better.

I have an idea how to properly solve this: Just dump core and when KDE is started next time, ask the user to report it. If the core cannot be dumped, save the backtrace. If the backtrace is useless, just shutdown anyway. You can tell the user upon next start, that he might want to install debug packages for x,y,z in case the application crashes again. This could be manageable by a system-setting:
---
Report crashes: Never, Always, Custom
Custom: [x] During shutdown [x] Whenever else it is bothersome [x] Save until start [x] Only when useful ...
Comment 46 Thomas Tanghus 2013-01-02 23:52:31 UTC
+1 to comment #43 

I spend a long time waiting for backtraces to be generated, installing debug packages, checking if the bug has been reported etc etc. One time I definitely *don't* wanna do it is during shutdown. It is an extremely bad user experience to have to even see that something has crashed during shutdown.
Try to make it possible to generate a backtrace or dump core or whatever so the user can have the option to examine it after next boot, but don't even popping a window during shutdown.
IMHO this doesn't even has to be configurable in the UI. It should be the standard, but maybe configurable via editing a config file.
Comment 47 wintonian 2013-01-07 01:13:51 UTC
Having had a quick scan through I haven't seen this mentioned since 2008, but it is always kwin that crashes for me. Sometime the shutdown procedure continues despite the appearance of drkonqi and with others drkonqi appears and shutdown appears to wait for you to decide what to do with drkonqi, but you are unable to interact with the dialogue, while task manager has already done so opening ksysguard to force close drkonqi isn't an option.

This is most annoying when using virtualbox and you forget to exit the VM before shutdown and it accordingly asks you what to do but kwin crashes and then you are unable to interact with the virtualbox dialogue and thus can't continue to shutdown and need to use the manual off -with.
Comment 48 Christoph Feck 2013-01-16 03:53:33 UTC
> it is always kwin that crashes for me

I did not find a KWin crash report from you.
Comment 49 wintonian 2013-01-16 09:16:11 UTC
Created attachment 76507 [details]
kwin backtrace
Comment 50 wintonian 2013-01-16 09:19:35 UTC
(In reply to comment #49)
> Created attachment 76507 [details]
> kwin backtrace

as I alluded to above I am unable to submit a report due to either not being able to stop the shutdown process or not being able to interact with the dialogue.

However I have found a kwin report that I have been unable to submit for some reason or other and have attached it, although I can't be certain that it is entirely relevant as I can't recall when this particular crash occurred.
Comment 51 Jekyll Wu 2013-01-19 00:57:40 UTC
OK, I probably will wirte another patch to make the waiting timeout in startkde configurable  or optional(meaning you can just disable it).  But it probably would take more time for me or anyone to write a  kcm for startkde/drkonqi to expose the option in GUI . 

Another thing I just don't understand :  why don't you  raise your voices after I posted the link for the review request in comment #36, but only after I have pushed the change?  I wrote in the review request: "Not sure whether it is worthwhile to make the timeout configurable at compile time or runtime." . So if you have raised you voices earlier about that mandatory and hardcoded timeout , then I probably wulld have spent more time instead of choosing the lazy way.
Comment 52 Jekyll Wu 2013-01-19 01:00:17 UTC
*** Bug 282389 has been marked as a duplicate of this bug. ***
Comment 53 Christoph Feck 2013-01-23 00:10:59 UTC
KWin crash from comment #49 is bug 308040.
Comment 54 Thomas Tanghus 2013-01-23 01:04:44 UTC
(In reply to comment #51)
> Another thing I just don't understand :  why don't you  raise your voices
> after I posted the link for the review request in comment #36, but only
> after I have pushed the change?  

You're right of course. I didn't pay attention to your review request at the time, and that wasn't very considerate. Sorry about that.
Comment 55 Jekyll Wu 2013-02-09 16:52:34 UTC
Git commit 63669a2af56811363ef53b9edb4e7ad111f5f9fd by Jekyll Wu.
Committed on 05/01/2013 at 20:53.
Pushed by jekyllwu into branch 'KDE/4.10'.

Make starkde wait for drkonqi in a configurable way

By default, startkde still waits for remaining drkonqis with 15mins
timeout during the logout/shutdown procedure.

Run the following commands to configure that behavior :

    $ kwriteconfig --file startkderc --group WaitForDrKonqi --key Enabled false
    $ kwriteconfig --file startkderc --group WaitForDrKonqi --key Timeout 900

There is no GUI yet, so they are hidden options.

M  +18   -14   startkde.cmake

http://commits.kde.org/kde-workspace/63669a2af56811363ef53b9edb4e7ad111f5f9fd
Comment 56 Ivo Anjo 2013-02-10 13:58:23 UTC
Thank you for adding that.
I think that is truly the KDE way -- if you don't like the default, you can change it :D
Comment 57 Felix Rohrbach 2013-06-08 14:50:40 UTC
So is this seen as fixed? Can it be closed?
Comment 58 Harald Sitter 2019-12-14 17:59:44 UTC
Should be fixed in Plasma 5.18+.