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".
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.
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'.
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.
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.
Same here, KDE 4.1 beta 2.
*** Bug 160970 has been marked as a duplicate of this bug. ***
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
*** Bug 168959 has been marked as a duplicate of this bug. ***
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.
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 #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 #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.
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?
*** This bug has been confirmed by popular vote. ***
*** Bug 141952 has been marked as a duplicate of this bug. ***
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
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)
On 4.3 I can confirm that even with DrKonqi open, the session is successfully terminated.
So no dev has ever even looked at this thing. Good that it's fixed itself.
(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.
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
I have fixed the problem that "it's fixed itself", so reopening.
*** Bug 251847 has been marked as a duplicate of this bug. ***
*** Bug 261354 has been marked as a duplicate of this bug. ***
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.
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?
*** Bug 283863 has been marked as a duplicate of this bug. ***
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.
*** Bug 286901 has been marked as a duplicate of this bug. ***
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.
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.
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
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()));
Still an annoyance in 4.8. Is there a good reason for not fixing this behavior, other than being low on the priority list?
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.
http://git.reviewboard.kde.org/r/107657/ I think the timeout should be done in startkde, not in Dr.Konqi .
My intention was to reset the timer if there was user activity present. But I got bored to go deeper on KDE code.
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
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
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
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).
(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.
>> - 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.
(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.
(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 ...
+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.
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.
> it is always kwin that crashes for me I did not find a KWin crash report from you.
Created attachment 76507 [details] kwin backtrace
(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.
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.
*** Bug 282389 has been marked as a duplicate of this bug. ***
KWin crash from comment #49 is bug 308040.
(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.
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
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
So is this seen as fixed? Can it be closed?
Should be fixed in Plasma 5.18+.