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

This is a discussion on How to kill running process -- kill -9 has no effect - Questions ; 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. ...

+ Reply to Thread
Results 1 to 5 of 5

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

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

  2. Re: How to kill running process -- kill -9 has no effect

    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


  3. Re: How to kill running process -- kill -9 has no effect

    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.

  4. Re: How to kill running process -- kill -9 has no effect

    Keith Keller wrote:

    > On 2003-11-07, Doug Laidlaw 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

  5. Re: How to kill running process -- kill -9 has no effect

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

    > Keith Keller wrote:
    >
    >> On 2003-11-07, Doug Laidlaw 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


+ Reply to Thread