[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