unkillable processes causes?

[David Magda]

Hello,

What are possible reasons for a process not being kill(1)-able in
Solaris (or Unix in general)? (Especially SIGKILL.)

Doing a quick Google search, one reason often given is that the
process has done an uninterruptable system call (usually related to
hardware). It's waiting for the call to return but, for whatever
reason, it doesn't. Therefore controll is never returned to the
process to receive the signal.

Are there any causes?

--
David Magda <dmagda at ee.ryerson.ca>, [url]http://www.magda.ca/[/url]
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

[Thomas Dehn]

"David Magda" <dmagda+trace030725@ee.ryerson.ca> wrote:

> What are possible reasons for a process not being kill(1)-able in
> Solaris (or Unix in general)? (Especially SIGKILL.)
>
> Doing a quick Google search, one reason often given is that the
> process has done an uninterruptable system call (usually related to
> hardware). It's waiting for the call to return but, for whatever
> reason, it doesn't. Therefore controll is never returned to the
> process to receive the signal.
>
> Are there any causes?

The process ignores the signal you are sending
(doesn't apply to SIGKILL on Solaris), use psig to check

The other thing I can think of is that the process actually
does respond to your SIGKILL, but its so slow that
you don't notice.


Thomas

[Darren Dunham]

David Magda <dmagda+trace030725@ee.ryerson.ca> wrote:

> Hello,

> What are possible reasons for a process not being kill(1)-able in
> Solaris (or Unix in general)? (Especially SIGKILL.)

Processes only respond to signals while in user space. If they're
executing a system call, the call must return before the signal can be
processed.

> Doing a quick Google search, one reason often given is that the
> process has done an uninterruptable system call (usually related to
> hardware). It's waiting for the call to return but, for whatever
> reason, it doesn't. Therefore controll is never returned to the
> process to receive the signal.

Right.

> Are there any causes?

Sure. Bug in kernel, bug in driver, limitation in driver.

Basically, If you put a lot of time and effort into writing a driver,
you can make it return, even in harsh situations for the hardware, but
it's difficult to take care of every situation.

Easier, faster, and cheaper for the developer is to just wait for the
hardware to "do the right thing". If it doesn't, then the driver can go
off into la-la land and the process calling it can't be killed.

In most situations, the unkillable process itself isn't that big a deal.
The process probably isn't taking any CPU time because the driver is
hosed. Even if you could kill the process, the underlying problem with
the driver or the hardware is still there preventing you from using that
device again.

In most situations this means that you need to do analysis with your
hardware and/or vendors to determine the resolution.

--
Darren Dunham [email]ddunham@taos.com[/email]
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

[Greg Andrews]

David Magda <dmagda+trace030725@ee.ryerson.ca> writes:

>Hello,
>
>What are possible reasons for a process not being kill(1)-able in
>Solaris (or Unix in general)? (Especially SIGKILL.)
>
>Doing a quick Google search, one reason often given is that the
>process has done an uninterruptable system call (usually related to
>hardware). It's waiting for the call to return but, for whatever
>reason, it doesn't. Therefore controll is never returned to the
>process to receive the signal.
>
>Are there any causes?
>

Besides the bugs that Darren mentioned, there is the situation where
the process is in the middle of I/O operations on a hard-mounted NFS
filesystem, and the NFS server is not responding (because it crashed
or the network is broken).

-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.

[Wayne]

David Magda wrote:

> Hello,
>
> What are possible reasons for a process not being kill(1)-able in
> Solaris (or Unix in general)? (Especially SIGKILL.)
>
> Doing a quick Google search, one reason often given is that the
> process has done an uninterruptable system call (usually related to
> hardware). It's waiting for the call to return but, for whatever
> reason, it doesn't. Therefore controll is never returned to the
> process to receive the signal.
>
> Are there any causes?

Besides the ones already mentioned, there *might* (I'm not sure)
be others. These may or may not apply to current (or any) Solaris
version, but hey, I'm willing to be informed (i.e. flamed) if I'm wrong:

The process may be stopped. A stopped process cannot respond
to signals until it is started again. (I seem to remember this
from AIX, maybe it applies to Solaris?)

The process may be dead already. Ps won't (at least in older versions)
correctly identify "zombie" processes as such. I think "top" will,
if you have it.

-Wayne

[Darren Dunham]

Wayne <flames@dev.nul> wrote:

> David Magda wrote:

>> Hello,
>>
>> What are possible reasons for a process not being kill(1)-able in
>> Solaris (or Unix in general)? (Especially SIGKILL.)

>> Are there any causes?

> Besides the ones already mentioned, there *might* (I'm not sure)
> be others. These may or may not apply to current (or any) Solaris
> version, but hey, I'm willing to be informed (i.e. flamed) if I'm wrong:

> The process may be stopped. A stopped process cannot respond
> to signals until it is started again. (I seem to remember this
> from AIX, maybe it applies to Solaris?)

Hm.. Certainly possible, but I am not able to cause that to occur. KILL
and INT both cause a "normal" but stopped process to terminate. I would
imagine even if signals were ignored, KILL would still work.

> The process may be dead already. Ps won't (at least in older versions)
> correctly identify "zombie" processes as such. I think "top" will,
> if you have it.

I'm unaware of any recent version of 'ps' failing to identify zombies.
Both /usr/bin/ps and /usr/ucb/ps should do so properly.

$ perl -e 'if (fork()) {sleep 20;}' &
[1] 15091
$ /usr/bin/ps -ef | grep def
root 15092 15091 0 0:00 <defunct>
$ /usr/ucb/ps ax| grep def
15092 Z 0:00 <defunct>

--
Darren Dunham [email]ddunham@taos.com[/email]
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >