Version: (using KDE KDE 3.4.0) Installed from: SuSE RPMs Sometimes applications crash and cannot be restarted. I just encountered this problem with kmail and OpenOffice. In many cases this is due to left processes (can I say the program has not crashed "enough"? ;-) ). People with the necessary knowledge can have a look at their process list and kill the respective processes manually (which are not always easy to identify though). I would like to suggest that KDE remembers the PID of the applications it starts. If one of them crashes and the user tries to restart it then KDE could check for the stored PID and (former) child processes. These processes could either be killed automatically or after asking the user. This might be configured in the .desktop files, too. This should not be difficult to realize but should save much time and anger.
How will KDE know if an app has crashed, but not died?
That doesn't make a difference in this case at all because dying applications shouldn't leave processes, too. I would check for such processes every time an application is started (again) and at least offer the user a dialog telling him what has been determined and let him decide (in case the behaviour in such situations has not been configured anywhere (e.g. in the icon .desktop file)). The message could be like this: "You are starting this application again. There are some processes left from the last time you started it. This need not be a problem. You can continue normally by selecting "no" below and in case of problems (application does not start up) select "yes" when you try again. Do you want these processes to be killed before starting the application? yes/no" The respective process IDs should be stored of all former starts not just the last one, of course.
I came across this problem too several times: Applications malfunction because of old dying/dead ghost processes lurking around. For unexperienced users, there's not way to solve this matter, except for leaving KDE and logging in again. Is there any way for KDE applications to check for dead remains on startup?
This discussion is far too generic. Which "problems"? Which "processes"? We shouldn't bother the user with how to workaround our bugs, we should fix those bugs in the first place. If an old kioslave makes kmail not restart properly, then kmail should detect that and kill that slave, or something. (But I have never seen that problem myself). If OpenOffice... well, this is bugs.kde.org, we don't handle OpenOffice.org bugs.
David, you mix up things. I explained "problems" as the failure to start up again. According to my experience a huge part of these problems (or rather occurances) can be solved by killing certain processes. I don't know what the technical reasons are, that's just what I observe. This in not generic in any unusable way. If a solution can be generic - why not? My suggestion is not intended to keep anyone from fixing bugs in an application (and certainly that wouldn't happen). The very generic problem is that there will always be bugs. A nice comment "This is going to be fixed soon" does not solve the problem of the user who has to log out (or, the necessary capability given, kill the processes manually). And considering OpenOffice: Why don't you like the idea that adding one feature makes dealing even with non-KDE-related software more comfortable? I understand you so that you want - for some unexplained reason - to unnecessarily leave the user with problems which will always occur from time to time.
On Thursday 26 May 2005 19:53, hauke@laging.de wrote: > I explained "problems" as the failure to start up again. Yes, but why? I never had a KDE program "fail to start up" because of earlier "processes" (which ones?). I had kmail and karm "startup problems" but only due to stale lockfiles, which is another matter. > According to my experience a huge part of these problems (or rather occurances) can be solved by killing certain processes. Which ones??? As long as you remain so vague, how can I even begin to understand what you're talking about? > I don't know what the technical reasons are, that's just what I observe. This in not generic in any unusable way. If a solution can be generic - why not? You ask for a generic solution to an unexplained problem? Where's my crystal ball? > And considering OpenOffice: Why don't you like the idea that adding one feature makes dealing even with non-KDE-related software more comfortable? You're dreaming. How on earth could KDE even start to figure out what OpenOffice does internally? And assuming we monitor processes for the processes they fork - if you click on a URL and konqueror is started (say by OpenOffice), and then you close OpenOffice (or it crashes, whichever), should we then kill that konqueror window simply because it was started by OpenOffice?? This doesn't make any sense. > I understand you so that you want - for some unexplained reason - to unnecessarily leave the user with problems which will always occur from time to time. Sigh... no I don't.
I accept that you never had such problems - but for how many problems is that true (if you have a look at the bug reports)...? I am not a programmer but I know what I am talking about. This is a real world effect. What kind of proof do you want? Let alone somebody else has already backed my claim. What is an "unexplained problem" for you? I say "this can be observed", "that solves the problem for the user" and "make this solution more comfortable". What kind of bug led to the problem is totally irrelevant. So is irrelevant what OpenOffice does internally. You argue with an in my opinion quite unusual case. I never had the problem that these crashed applications had started others. But even if so: The main argument is that the user would log out of KDE completely otherwise. The only advantage of not offering this "clean up service" is that it would not happen that something happens what the user does not expect (e.g. if he was not aware of how certain apps were started). But that seems quite theoretical to me. This problem could be solved by adding the possibility to configure what the executables are which belong to the core application. But the value gain for the user would be so small and the effort so big that I would not suggest that. If you want to do it better you could add an "experts" checkbox and pop up a list of processes to be killed with the option to deselect some. The "called from OpenOffice" konqueror could survive then.
As long as you don't say which process you have to kill for which other process to start correctly, this discussion is going nowhere. I don't want "proof", I want a concrete example instead of the theoretical "some processes don't start when some processes are still running".
I have been to the Linuxtag fair in Berlin today and talked about this problem with several people at the KDE booth and even with those from Gnome (where the KDE guys sent me to in order to check how the rest of the world handles this). The results: 1) EVERYONE has accepted the problem. I still experience this with kmail/kontact, the other ones mentioned Amarok as a frequent source of this problem. 2) MacOS (really, hard to believe...) ALREADY does something similar (the Gnome guys said). There the process start up feedback is directly related to the process state (in contrast to the one in KDE...) and you are given the possibility to kill a process even before it has opened an X Window (after that it can be killed in Linux by <Ctrl>-<Alt>-<Esc>). 3) The Gnome guys admit that the solution should be located central in the desktop/window manager. One of the KDE guys holds the argument of comment #4 - that one should rather fix the bugs in the applications than create such a generic "solution". But he himself pointed out that he had reported this problem several times to the Amarok developers without them having fixed it yet. The other KDE guys hold my opinion (which doesn't prevent application bugs from getting fixed, of course). I would like to make a comparison with other levels of software. Refusing this kind of control in the instance starting other processes (the desktop in this case) would be equivalent to the X Server refusing to kill a dead window (which can be done by <Ctrl>-<Alt>-<Esc>; "Why kill the app if you can kill the whole X server and login again?"). The other analogy: Imagine the kernel would not allow you to kill processes. "Why be able to kill processes if you can reboot the system instead?" It is obvious that such arguing would be rediculous. It seems very strange to me that what is obviously for the kernel and the X server should be the opposite(!) in an analogous situation, just at another software level (desktop manager). If we all relied on the quality of software we could still use DOS - because who needs any kind of forcable control if every component of the system is supposed to be cooperative (which implies "bug free")? And besides the theoretical arguing: If EVEN MacOS offers that (and Gnome might in the future) it is obvious that this would be a good addition to KDE.
Unless I misunderstand something there's a mixup here. Yes it would be really nice if the process startup feedback was related to the process state - but this is for another bug report. I still don't see what it is in kmail or amarok that makes it necessary to kill some process before they can start up. Let me point out the huge risk from such a "There are some processes left from the last time you started it, want to kill them?" solution: 1) In a gnome environment, you start kmail. This in turn, starts dcopserver and kdeinit (in kde3) 2) Then you start another kde app, say kword, and you start typing text there. 3) kmail crashes. You launch it again, the environment suggest "you have processes that kmail has started automatically, want to kill them?" - and if you say yes, it will kill dcopserver and kdeinit, right? Those were started by kmail. 4) boom, kword disappears. In kde3 when you killed dcopserver, all kde apps would be killed. "Mac OS and gnome do it" isn't enough information. What do they do -exactly-? If they kill any process that were started by the application [I'm not even sure there's a portable way of detecting that, especially after the death of the parent process...] then they create the above problem for sure. Anyway, if anyone even wants to start implementing something like this, he will need a reproduceable way to trigger this problem (an app that doesn't want to start because of some child processes), so let's start with that :)
I would recommend filing individual bug reports against apps that are behaving in this way. There isn't a clean, sane, and generic way to detect and fix this, sorry. :)