Mark Haney posted on Fri, 28 Aug 2009 14:34:52 -0400 as excerpted: > I've just upgraded to 4.3.0 and I've got a question. On my 'taskbar', > if an app crashes (like Firefox just did trying to play a flash video) > I'm getting a 'button' on the taskbar of the app that just won't go > away. I have 2 currently, one from evolution and one from Firefox. > > Does anyone know how to make those go away? Is anyone else seeing this > problem?
I haven't seen the problem and don't really know how to make them go away (well, I do if it's as I expect, but the cure is likely to be considered worse than the problem), but I think I know what's happening: Background: In Linux (and I'd suspect most Unixen tho I have no experience or knowledge other than Linux to back that up), every application has a parent. If the parent "disowns" the application, then the application's parent becomes init itself, init being the first userland application started by the kernel, with various functions... When an application terminates, the kernel keeps its context around so the parent can make use of various information from its former child process. When the parent is done, it (according to my understanding) tells the kernel it can clean up what's left, and that's when the rest of the process cleanup takes place, including release of any memory the process leaked and didn't properly release previously, etc. Processes that have terminated but that the parent process has not yet cleaned up are said to be "zombie" processes. Once in awhile, if you have the process status column displayed in top or (I think) ksysguard (aka system monitor, I said "I think" because I'm not sure ksysguard exposes that info, but I think it does, as an optional column), or if you enable a status option for ps, you'll see such zombie processes, normally marked with a "z". (FWIW, the most common status is sleeping, the application is waiting for something and is sleeping until it happens, this is normally denoted with "s".) Normally, zombies are reasonably rare, and don't show up often, because the state lasts only a very short period (fractions of a second) if the parent harvests its children and cleans up properly (telling the kernel it's OK to do so), but some processes aren't normally equipped to manage children as they don't expect to launch any, and thus don't harvest the zombies if for some reason they /do/ launch one. In other instances, the child may have terminated abnormally and for various reasons the parent isn't prepared to harvest what it was left with. Unfortunately, because the kernel can't clean up the zombies until the parent says it can, if the parent doesn't give permission, the zombies just sit there... until the parent itself terminates. That's therefore the way such zombies are ultimately cleaned up, the parent terminates and the zombies are cleaned up as the parent is cleaned up. But as I said, the cure may well be considered worse than the problem, if the parent is a critical part of X or KDE itself. In that case, to cleanup, you'd have to shutdown KDE (and/or X) and either continue at the text console or respawn *dm if you have a graphical X login manager. That's not always convenient, and unfortunately, it seems such zombies appear at the least convenient times. I'm not positive what you're seeing is zombie processes, but it does sound like it. Note that both of the apps in question are non-kde. KDE has it's own methods of dealing with kde apps that crash, but may not be prepared to cope with crashing gtk/gnome apps, which both firefox and evolution are. Ultimately, the easiest solution (certainly from KDE's perspective, the firefox and evolution devs I'm sure don't find it to easy or the problem wouldn't be occurring) is probably to fix those apps so they don't crash in the first place. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
