[100693] in RedHat Linux List
Re: Killing a process
daemon@ATHENA.MIT.EDU (Cameron Simpson)
Sun Nov 22 23:41:03 1998
Date: 23 Nov 1998 04:39:38 -0000
X-Original-To: redhat-list@redhat.com
From: Cameron Simpson <cs@zip.com.au>
Reply-to: cs@zip.com.au
To: redhat-list@redhat.com
Cc: shifter@zvisions.com
Resent-From: redhat-list@redhat.com
On 23 Nov 1998, in message <Pine.LNX.4.05.9811221629110.12879-100000@kachinahost.zvisions.com>
Shafer Stockton <shifter@zvisions.com> wrote:
| Recently I ran into several processes started by a user that I could not
| kill as root.
Happens sometimes, but only when something else is sick as well.
| I thought a reboot would take care of it, and it did.
This is a method of extremis.
| The
| only problem was I had to hard reboot because of the open files in use by
| those processes.
Yeah. Make sure you do a sync before hitting the button - limits the
damage you'll do to your filesystems (yes fsck cleans things up at
boot, but some things can't be cleaned up, and others can have the
wrong decisions made about 'em).
| My questions is.. is there some other method for killing a process than
| kill -9??
No. And you should only use a 9 after failing with a 15 (kill's default
- SIGTERM). A TERM is the right first attempt, because a process can
catch it and do necessary tidyup before dying. A SIGKILL (kill -9)
should only be used after this.
If a KILL fails, the process _is_ dead (it will never get scheduled
again, and most of it's state will be tidied up, too). If it doesn't go
away, one of two things obtains:
- Usually, it's simply that its parent hasn't waited for it.
After death, the process slot in the process table remains allocated
as a placeholder, storing the exit status (reason for death, accumulated
CPU time stats etc), ready for collection by its parent.
Do a "ps al" and check out its parent (PPID column). If it's 1,
it's an orphan and init will clean it up. Which should happen immediately,
so if it hangs around, something is sick.
If its not a 1, then check out that parent. Naively written X
sessions and so forth frequently fail to wait for their children.
Don't stress about it; it'll go away when the session ends normally anyway.
- Less often, the process can't die because it's caught on some unreleased
resource. NFS mounts whose server ends are down can do this, as can some
other oddneeses. Had a netscape do it the other day - our current theory
for that one is a power management problem on the machine in question,
spinning the drive down, and linux not recovering the particular I/O
in progress at the time afterwards (since everything else proceeded
happily afterwards, but the netscape was totally wedged, blocked in D
state, which is "short term disc I/O wait" - not normally anything except
transient).
Unless it's causing other problems, leave it alone and shut the machine down
as some convenient time.
--
Cameron Simpson, DoD#743 cs@zip.com.au http://www.zip.com.au/~cs/
I can't count the number of times that some asshole driver has cut me off at
an intersection, given me about two inches of road space on the very edge of
the road or just stopped and parked his car in front of me in traffic. I am
an agressive cyclist, now. I wasn't once, but there's no way for me to be
anywhere but standing on the curb if I don't impose myself on the road. If
the average driver pretended to show some simple courtesy to me, I'd pretend
to follow the laws that I see drivers flouting anyway.
- Michael R M Hoye <mhoye@descartes.uwaterloo.ca>
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
