[gentoo-amd64] Re: KDE 4.3.0 'panel ghosts'

[Duncan]

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