[gentoo-amd64] KDE 4.3.0 'panel ghosts'

[gentoo-amd64] KDE 4.3.0 'panel ghosts'

[Mark Haney]

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?

-- 
Interdum feror cupidine partium magnarum Europae vincendarum

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

[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

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

[Jesús Guerrero]

On Sat, August 29, 2009 06:08, Duncan wrote:
> 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 know nothing about evolution, and very little about kde 4.3. But
if the task manager is indeed showing zombie processes, you might be
able to correct this by killing them. You can send SIGKILL using
top, kill, htop or whatever suits you better, to all the firefox and
xulrunner processes in the background. About evolution, I don't know.
If once they are gone from the top/htop list they still show in the
taskbar, then there's something else to it than zombie processes, and
it's probably a kde bug.

> 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.

I am not a man of faith. I'd rather believe in facts.

Firefox has always been buggy, and will always be buggy. It's a hog,
it's big, and gecko doesn't help either. If fixing firefox was an
easy task then it would have done time ago. Plus a big part of the
crashes are due to buggy extensions (however firefox should prevent
that as well, just like the kernel prevent buggy apps from locking
your machine, but...).

-- 
Jesús Guerrero

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

[Frank Peters]

> 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?
> 

As others have indicated, you'd need to manually kill the processes.

Open an X terminal and issue the command:

ps ax

This will produce a list similar to the following, which is taken
from my own machine:

663 pts/2    Ss+    0:00 sh
674 ?        Ss     0:00 dhcpcd -R -M -h  -t 120 -L -Y eth0
678 ?        Sl     0:00 pdnsd -d
684 ?        S      0:02 sylpheed
697 ?        Sl     0:32 skipstone-bin
994 pts/0    R+     0:00 ps ax

The names of all running processes are shown at the right.  Once you have
found the process in question (firefox or evolution), make a note of the
number at the left.  This is the process id, or PID.  Then issue the command:

kill -s 9 PID

This will terminate those processes.

Sometimes, a process can be associated with several PID's.  Make sure to
kill, using the above command, all of the PID's that are involved.

Frank Peters

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

[Duncan]

Frank Peters posted on Sat, 29 Aug 2009 10:52:47 -0400 as excerpted:

> The names of all running processes are shown at the right.  Once you
> have found the process in question (firefox or evolution), make a note
> of the number at the left.  This is the process id, or PID.  Then issue
> the command:
> 
> kill -s 9 PID
> 
> This will terminate those processes.
> 
> Sometimes, a process can be associated with several PID's.  Make sure to
> kill, using the above command, all of the PID's that are involved.

Note that there's also the killall command, which according to the 
manpage, kills "processes by name".  Of course, it'll kill /all/ the 
processes by that name, so may not be what you want if you have multiple 
separate firefox processes running at the same time, for instance, but 
it's very useful, none-the-less, since where it /can/ be used, it saves 
the step of looking up the pid.

Also, with both kill and killall, the "s " shouldn't be needed.  kill -9 
PID or killall -9 name should work, tho both will also take the -s form, 
too.  FWIW, they'll also take the named signal.  -15/-TERM is the default 
if no signal is specified.  That tries to kill an application gracefully, 
giving it time to save its work or whatever.  As such, it may or may not 
work.  -9/-KILL is the "kill and I really mean it" signal, NOT allowing 
the application a graceful exit, simply directing the kernel to kill it 
outright.

There are, however, instances where even -KILL/-9 won't get rid of the 
process. Zombies are one (for them, killing the parent process works, 
where possible).  "Uninterruptable sleep" is another, normally shown with 
a "D" in ps, top, and similar status outputs.  "Uninterruptable sleep" is 
triggered for some types of I/O (input/output, reading/writing to the 
disk, for instance).  Where this can become a problem is for example when 
you yanked the USB stick without unmounting (aka safely removing) it, and 
the application doesn't know it's gone -- it can get stuck in 
uninterruptable sleep in such a case, and rebooting is about the only fix 
for that.  Another example would be the problems people had with certain 
external drives awhile back, where the drive was set for aggressive power-
saving, but didn't conform to standards (the drivers solved it for MS 
users), so the kernel didn't know the drive had gone to sleep and 
couldn't properly wake it up.  The app would therefore try to write 
something to it, and would hang indefinitely as a result.  As mentioned, 
rebooting can be the only way to get rid of processes hung in 
"uninterruptable sleep" mode.

The above is for Linux.  The BSDs, Solaris, etc, may be slightly 
different.

-- 
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

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

[Frank Peters]

On Sat, 29 Aug 2009 17:39:21 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 
> Note that there's also the killall command, which according to the 
> manpage, kills "processes by name".  Of course, it'll kill /all/ the 
> processes by that name, so may not be what you want if you have multiple 
> separate firefox processes running at the same time, for instance, but 
> it's very useful, none-the-less, since where it /can/ be used, it saves 
> the step of looking up the pid.
> 

Yes, that's all quite true, but there still may be problems.

After I start a single instance of firefox, here is what "ps ax" shows:

1987 ?        S      0:00 /bin/sh /usr/local/bin/firefox
1999 ?        S      0:00 /bin/sh /opt/firefox35/run-mozilla.sh /opt/firefox35/firefox-bi
2003 ?        Sl     0:00 /opt/firefox35/firefox-bin

There are already three processes associated with this single instance,
and the names are not obvious.  To kill all of them, it will usually suffice
to kill only the last process which in this case is 2003.  But that
strategy won't always work.  It's always best to check with ps and kill
what needs to be killed.

> Also, with both kill and killall, the "s " shouldn't be needed.  kill -9 
> PID or killall -9 name should work, tho both will also take the -s form, 
> too.  FWIW, they'll also take the named signal.  -15/-TERM is the default 
> if no signal is specified.  That tries to kill an application gracefully, 
> giving it time to save its work or whatever.  As such, it may or may not 
> work.  -9/-KILL is the "kill and I really mean it" signal, NOT allowing 
> the application a graceful exit, simply directing the kernel to kill it 
> outright.
> 

Yes, that's also very true, but I figure that if Flash Player is crashing
firefox, a "kill -s 9" is in order.  The best course would be to first attempt
a "kill PID" with no options.  This will allow the process, as you indicate,
to close any open file handles, etc.  But if "kill PID" should fail, then
"kill -s 9 PID" will almost certainly stop the process in a quick and brutal
fashion.  Again, use the ps command to check the result.  Sometimes, however,
as you indicate, even "kill -s 9" will fail and a reboot is the only way to
eliminate the process.

Frank Peters

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

[Mark Haney]

Frank Peters wrote:
> On Sat, 29 Aug 2009 17:39:21 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Note that there's also the killall command, which according to the 
>> manpage, kills "processes by name".  Of course, it'll kill /all/ the 
>> processes by that name, so may not be what you want if you have multiple 
>> separate firefox processes running at the same time, for instance, but 
>> it's very useful, none-the-less, since where it /can/ be used, it saves 
>> the step of looking up the pid.
>>
> 
> Yes, that's all quite true, but there still may be problems.
> 
> After I start a single instance of firefox, here is what "ps ax" shows:
> 
> 1987 ?        S      0:00 /bin/sh /usr/local/bin/firefox
> 1999 ?        S      0:00 /bin/sh /opt/firefox35/run-mozilla.sh /opt/firefox35/firefox-bi
> 2003 ?        Sl     0:00 /opt/firefox35/firefox-bin
> 

This is interesting.  However, I don't think it's a defunct process.
Currently I have 2 firefox windows (not tabs) open.  In both windows I
have 3 tabs.  However, I have 3 'taskbar buttons' of firefox.  2 'legit
ones' and one a 'shadow' of the existing one.  When I ran 'ps aux | grep
firefox' I see this:

markh@octavian ~ $ ps aux | grep firefox
markh    12288 13.4 11.4 863540 234916 ?       SLl  11:27   4:49
/usr/lib64/mozilla-firefox/firefox
markh    16714  0.0  0.0  88820   740 pts/4    S+   12:03   0:00 grep
--colour=auto firefox


I don't see any references to firefox anywhere else.  This is a minor
issue, but is a bit irritating.

-- 
Interdum feror cupidine partium magnarum Europae vincendarum

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415