Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: when does kill -9 pid not work?
Message-ID: <2339@auspex.auspex.com>
Date: 5 Aug 89 18:21:37 GMT
References: <20495@adm.BRL.MIL>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 41

>I had an infinite loop in my boot loader, and I couldn't kill the DOS task
>via a
>kill -9 pid
>which I always though always worked (I tried doing it as rooot after my own
>account didn't work).

Nope.  Processes in UNIX (or, at least, AT&T-derived UNIXes, including
4.xBSD), when blocked, are either sleeping at "positive" or "non-positive"
priorities.  (The quotes are there because all priorities are
numerically >= 0; they weren't in V6, but they're stored in a "char",
and I suspect when they ported V7 to the Interdata machines, said
machines' C implementation had unsigned "char"s, so they fixed the
problem by adding PZERO to the priority values, so "positive" means ">
PZERO".)

A sleep at a "positive" priority is interruptable; if a signal arrives,
the process is woken up.  A sleep at a "non-positive" priority is not
interruptable; the process stays blocked until it's explicitly woken up.
The idea is that, for example, if a process is holding onto some
critical resource, it will sleep at a "non-positive" priority, since an
"interrupted" sleep causes the moral equivalent of a "longjmp", so the
process has no chance to release said critical resource.  In general, if
the process has done something that requires undoing, it would sleep at
a "non-positive" priority.

In more recent versions of UNIX, including S5Rn (for some value of "n"
<= 2) and SunOS 3.2 and later (which picked this up from S5), you can
specify that an interrupted "sleep" should, instead of "longjmp"ing,
just return 1 (in these later versions, it returns 0 if not
interrupted), which gives the process a chance to release critical
resources, etc..  *Some* cases of sleeps at "non-positive" priorities
can be replaced with interruptable sleeps in those systems; I don't know
that all can, though, since it may still be extremely difficult or
impossible to undo anyting the process has done in the kernel.

(In addition, processes sleeping inside the forced "close" of all open
descriptors when exiting can't be killed, either; they're already
dead....)

Presumably, the process in question was sleeping at a "non-positive"
priority.