How to kill running process -- kill -9 has no effect

Hello,

I'm running into a problem with scp under some conditions that
are associated with transferring multiple GB files to a
RH 8.0 (kernel 2.4.18) system on a Dell Poweredge w/ 8 cpus
and lots of memory and disk space.

Scp for some reason starts using lots of cpu, and top says
that 50%-75% of cpu time is spent on system (as opposed to user).
The box stays up, but every other process slows to a crawl.
We've let it run for the better part of a day (16 hours)
before power cycling, and nothing changes (neither better nor
worse).

The scp process cannot be killed although top says it is running
(status R) and therefore it should be killable. kill -9 has
no effect -- the kill command returns and the process continues
running.

(Interestingly, renice does change the priority as reported by
top, although the priority change has no effect either --
scp still using lots of cpu and all other processes very slow.)

Is the presence of an unkillable running process a kernel bug?

If you have any comments either on scp or on unkillable processes,
I'd be interested to hear about it.

Thanks for your help,
Robert Dodier

Robert Dodier wrote:

> Hello,
>
> I'm running into a problem with scp under some conditions that
> are associated with transferring multiple GB files to a
> RH 8.0 (kernel 2.4.18) system on a Dell Poweredge w/ 8 cpus
> and lots of memory and disk space.
>
> Scp for some reason starts using lots of cpu, and top says
> that 50%-75% of cpu time is spent on system (as opposed to user).
> The box stays up, but every other process slows to a crawl.
> We've let it run for the better part of a day (16 hours)
> before power cycling, and nothing changes (neither better nor
> worse).
>
> The scp process cannot be killed although top says it is running
> (status R) and therefore it should be killable. kill -9 has
> no effect -- the kill command returns and the process continues
> running.
>
> (Interestingly, renice does change the priority as reported by
> top, although the priority change has no effect either --
> scp still using lots of cpu and all other processes very slow.)
>
> Is the presence of an unkillable running process a kernel bug?
>
> If you have any comments either on scp or on unkillable processes,
> I'd be interested to hear about it.
>
> Thanks for your help,
> Robert Dodier

What is the status? As root do a ps -eaf and see if it is status "D". If so,
fergetaboutit. You can't kill a process that is in "uninteruptable sleep"
mode. You have to reboot to get rid of it. The only time I've seen it on my
machine is when I have KpilotDaemon loaded with Slackware 9.1 and I try to
access my Palm via USB with pilot-xfer (or J-pilot.). It just hangs the
window and the KpilotDaemon goes into "D" status.

(If you are going to use J-pilot, than either kill KpilotDaemon upon boot
up, or set it to not load (via Kpilot application.) )

Al

Robert Dodier wrote:

> Hello,
>
> I'm running into a problem with scp under some conditions that
> are associated with transferring multiple GB files to a
> RH 8.0 (kernel 2.4.18) system on a Dell Poweredge w/ 8 cpus
> and lots of memory and disk space.
>
> Scp for some reason starts using lots of cpu, and top says
> that 50%-75% of cpu time is spent on system (as opposed to user).
> The box stays up, but every other process slows to a crawl.
> We've let it run for the better part of a day (16 hours)
> before power cycling, and nothing changes (neither better nor
> worse).
>
> The scp process cannot be killed although top says it is running
> (status R) and therefore it should be killable. kill -9 has
> no effect -- the kill command returns and the process continues
> running.
>
> (Interestingly, renice does change the priority as reported by
> top, although the priority change has no effect either --
> scp still using lots of cpu and all other processes very slow.)
>
> Is the presence of an unkillable running process a kernel bug?
>
> If you have any comments either on scp or on unkillable processes,
> I'd be interested to hear about it.
>
> Thanks for your help,
> Robert Dodier
Kill -15 seems to get the really obstinate ones. I note that top uses kill
-15.

Doug.
--
Registered Linux User No. 277548.
They say lightning never strikes twice in the same place. My typing is
about as accurate. Apologies for any typos that slip in. - Doug.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2003-11-07, Doug Laidlaw <laidlaws@myaccess.com.au> wrote:
> Kill -15 seems to get the really obstinate ones. I note that top uses kill
> -15.

Please read the man page for kill--signal 15, SIGTERM, may be blocked,
but signal 9, SIGKILL, may not. If a process doesn't respond to KILL,
there's a bigger problem.

- --keith

- --
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/qxHDhVcNCxZ5ID8RAsO3AJ4lKcELVx9BbU9kPxeV7BOtko64XA CeON2g
M1ys8kAnqGwe2QmEOYXSCQQ=
=JWLo
-----END PGP SIGNATURE-----

Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> writes:

> On 2003-11-07, Doug Laidlaw <laidlaws@myaccess.com.au> wrote:
> > Kill -15 seems to get the really obstinate ones. I note that top uses kill
> > -15.
>
> Please read the man page for kill--signal 15, SIGTERM, may be blocked,
> but signal 9, SIGKILL, may not. If a process doesn't respond to KILL,
> there's a bigger problem.
>
...<snip>...

I don't know the particulars about linux, but in classic unix situations,
if a process makes a system call (like opening a device), it can't die
until it returns from the system call. Maybe the process is accessing
a device driver that's a little flaky?

Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

> On 2003-11-07, Doug Laidlaw <laidlaws@myaccess.com.au> wrote:
> > Kill -15 seems to get the really obstinate ones. I note
> > that top uses kill -15.
>
> Please read the man page for kill--signal 15, SIGTERM, may be blocked,
> but signal 9, SIGKILL, may not. If a process doesn't respond to KILL,
> there's a bigger problem.

Hi, it's to OP again. The process in question is runnable
(status R, not D) and yet it does not die when kill -9 is issued.
What is the "bigger problem" to which you allude?

Here is a possible scenario: the process has executed a system
call so actually the kernel is executing on its behalf. The process
has a pending SIGKILL but it can't be delivered until the system
call returns (right?). Thus the process can be runnable, using cpu
(since the cpu time used by the kernel on its behalf is credited
to the process, right?), and yet the process is not killed by kill -9.
Can someone comment on how realistic that is -- I've made a couple
of assumptions that I'm not entirely sure about.

Assuming that there is a system call which is not returning for
some reason -- how can I find out what it is? The program in
question is installed and maintained by someone else so (e.g.)
recompiling with some different flags is not feasible.

Thanks so much for your time. I appreciate your help.

Robert Dodier

On Sun, 09 Nov 2003 08:13:21 -0800, Robert Dodier wrote:

> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>
>> On 2003-11-07, Doug Laidlaw <laidlaws@myaccess.com.au> wrote:
>> > Kill -15 seems to get the really obstinate ones. I note
>> > that top uses kill -15.
>>
>> Please read the man page for kill--signal 15, SIGTERM, may be blocked,
>> but signal 9, SIGKILL, may not. If a process doesn't respond to KILL,
>> there's a bigger problem.
>
> Hi, it's to OP again. The process in question is runnable
> (status R, not D) and yet it does not die when kill -9 is issued.
> What is the "bigger problem" to which you allude?
>
> Here is a possible scenario: the process has executed a system
> call so actually the kernel is executing on its behalf. The process
> has a pending SIGKILL but it can't be delivered until the system
> call returns (right?). Thus the process can be runnable, using cpu
> (since the cpu time used by the kernel on its behalf is credited
> to the process, right?), and yet the process is not killed by kill -9.
> Can someone comment on how realistic that is -- I've made a couple
> of assumptions that I'm not entirely sure about.
>
> Assuming that there is a system call which is not returning for
> some reason -- how can I find out what it is? The program in
> question is installed and maintained by someone else so (e.g.)
> recompiling with some different flags is not feasible.
>
> Thanks so much for your time. I appreciate your help.
>
> Robert Dodier

use rsync to transfer the files instead of ssh.

Good Luck

--
GNU/Linux is God
get used to it
declinton@sympatico.ca
Linux User # 276385