Very Computer

kill -9

if not then the process is in a kernel state most likely waiting for I/O

If 'kill -9' doesn't do the trick, then try 'reboot'.

How to kill process which not killed by 'kill' ?

try kill -9.

if a simple kill pid doesn't work, it usually means the process is trapping the
kill signal. the -9 option says kill, damn any traps that might be in your way.

You can't trap SIGKILL. If the process doesn't get to see the signal, this
probably means that its thread is completely blocked, and has nothing to do
with "trapping" the signal.

In my experience, this often occurs when the kernel gets stuck in
a cv_wait(9F). So use cv_wait_sig(9F), cv_timedwait(9F) or cv_timedwait_sig(9F)
to get around this (if it is indeed the cause of the problem.)

Arindum

Coming at this from a different angle, I've noticed that if I run a
shell script with a really long sleep in it, and try to kill it (even
with -9), it doesn't die until the sleep is finished.  I've never
bothered to find out definitely why this is.

My guess is that if the process is sleeping, the scheduler doesn't
give it any cpu time for processing until the designated wake-up time,
so it never gets the chance to receive the kill until then.  If anyone
can confirm/deny this, and explain it in a less dumb way, I'd be
grateful.

This feature can be a real * if you've just written a really
clever script to automate the killing of particular processes and
decide to test it by killing simple scripts with long sleeps in them
(BTDT).

Cheers, Jim.

Cheers, Jim.

Back in my Digital UNIX kernel days, we considered a process
that was unkillable with SIGKILL to be the victim of a serious OS bug.
You should never have to reboot to clear one of these processes,
but this appears to be acceptable on Solaris. Oh, well.

BSD-based kernel's alway clear the interruptible wait state of
the target process of a caught or terminating signal. In other words,
you can be in the longest 'sleep()' ever recorded when the
signal comes in, and you would be awakened immediately.
When you again ran, you'd die or take the signal. As I recall,
for SIGKILL the process priority was raised to expedite the
process' demise.

It's hard to imagine that Solaris doesn't use the same approach.

__________________________________________________

Bright Tiger Technologies:  Resource-management software
for building and managing fast, reliable web sites
See us at http://www.veryComputer.com/

125 Nagog Park
Acton, MA 01720
Phone: (978) 263-5455 x177
Fax:   (978) 263-5547

Your guess isn't correct.  The shell will fork() and waitid().
When the signal is sent, the shell will wake up and handle the
signal.  But the sleep won't wakeup because sleep's parent process
went away.  You need to kill the sleep as well.  BTW, I can't recreate
your problem on my Solaris 2.5.1, 2.6 or 7 machines.

Quote:> > This feature can be a real * if you've just written a really
> > clever script to automate the killing of particular processes and
> > decide to test it by killing simple scripts with long sleeps in them

Yup.

Quote:> Back in my Digital UNIX kernel days, we considered a process
> that was unkillable with SIGKILL to be the victim of a serious OS bug.
> You should never have to reboot to clear one of these processes,
> but this appears to be acceptable on Solaris. Oh, well.

The only thing I know of that won't be killed dead by a SIGKILL is a
process blocked waiting on IO.  In the latter case, the KILL will
be delivered as soon as the block clears.

Quote:> BSD-based kernel's alway clear the interruptible wait state of
> the target process of a caught or terminating signal. In other words,
> you can be in the longest 'sleep()' ever recorded when the
> signal comes in, and you would be awakened immediately.
> When you again ran, you'd die or take the signal. As I recall,
> for SIGKILL the process priority was raised to expedite the
> process' demise.

The Solaris signals are stored as a bitmask.  Multiple
signals can be outstanding.  Some signals can be blocked, deferred,
ignored, or have signal handlers added to run more code.  A process
cannot block some SIGNALS (KILL, STOP).  So the action taken when a
SIGKILL is received will be to exit, irregardless of any other
pending signals.

I don't see any avantage to changing the process priority for a
process recieving a signal, since that process will get placed
back in the run queue rather quickly anyway.  The regular
scheduler should be able to handle it well.  I could imagine one
thinking the scheduler paid special attention to KILLed processes,
but I suspect that would be a natural fallout of the UNIX
scheduler.  Come to think of it, I rarely find machines with such
a large run queue that I would have to wait long at all to get a
signal serviced.  15 years ago, that wasn't always the case ;-)

The real irritating thing about SIGKILL is that the process has
no ability to run any signal handling code.  For example, Netscape
navigator sets a lock file in the users $HOME/.netscape directory.
Sending SIGKILL to netscape will leave the lock since netscape has
no ability to run any code to clean up the lock.  Later instances
of netscape will complain about the lock.  Yet another reason not
to use SIGKILL unless other signals haven't worked.  I recommend a
set to try: TERM (default), HUP, INT, QUIT, ABRT, and then maybe KILL.
Most processes do the right thing with TERM. ABRT will force a core
dump.  KILL kills it dead.

Solaris signal handling is largely derived from Posix with some
BSDisms added for variety.
 -- richard

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

If a process can't be killed w/ -9 it is subject of a kernel bug.
(He probably didn't try -9)

Quote:>BSD-based kernel's alway clear the interruptible wait state of
>the target process of a caught or terminating signal. In other words,
>you can be in the longest 'sleep()' ever recorded when the
>signal comes in, and you would be awakened immediately.
>When you again ran, you'd die or take the signal. As I recall,
>for SIGKILL the process priority was raised to expedite the
>process' demise.
>It's hard to imagine that Solaris doesn't use the same approach.

A killed process will die, the only time a process won't die is when
it is stuck in the kernel; one of those "shouldnt' happen" situations.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

<
< [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
<

<
< >Back in my Digital UNIX kernel days, we considered a process
< >that was unkillable with SIGKILL to be the victim of a serious OS
bug.
< >You should never have to reboot to clear one of these processes,
< >but this appears to be acceptable on Solaris. Oh, well.
<
< If a process can't be killed w/ -9 it is subject of a kernel bug.
< (He probably didn't try -9)
<

 I've seen NFS-mounted program not respond to SIGKILL on Solaris 2.5
when NFS server became unavailable. Was it really Solaris or just me?

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

By default, mounts are "intr" ; I think SIGKILLs will not be honored in
such cases, but SIGINT will.  (Which is weird, I admit).  I haven't
tried this for a long time, though.

If the filesystem is not mounted "intr" (and that wasn't the default a long
time ago), then the program will hang until the server recovers, if
the program hangs in disk wait.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.