Xref: utzoo comp.unix.questions:6787 comp.unix.wizards:8153 comp.unix.microport:561
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!limes
From: limes@sun.uucp (Greg Limes)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport
Subject: Re: Trouble killing processes in SysV/AT
Message-ID: <51443@sun.uucp>
Date: 30 Apr 88 06:06:03 GMT
References: <3950@killer.UUCP> <3951@killer.UUCP> <468@micropen>
Reply-To: limes@sun.UUCP (Greg Limes)
Organization: Sun Microsystems, Mountain View
Lines: 47

In article <468@micropen> dave@micropen (David F. Carlson) writes:
>In article <3951@killer.UUCP>, wnp@killer.UUCP (Wolf Paul) writes:
>> Can anyone enlighten me as to what causes a process to become "immortal"
>> in System VR2,  or Microport UNIX System V/AT, to be more specific?
>> 
>This "prblem" is not a Micrport issue at all: it is UNIX all the way.
>
>> I have encountered this a number of times, where it would be impossible
>> even for root to kill a process; if the parent process of the "immortal"
>> process is killed, the child attaches itself to init, PID 1.
>> What causes a process to refuse to die? I thought signal 9 (kill) could
>> not be intercepted or ignored?
>
>If you are technically minded and want a real answer read:
>	"The Design of the UNIX Operating System" by Maurice Bach.
>
>The quick answer is that any process that is in the kernel with a WCHAN
>will not go back to user mode until that channel is awoken.  Who will
>awaken it?  Two choices:  a device driver interrupt or a kernel timer
>interrupt.  In all likelihood your ill-behaved process is waiting in
>a poorly written device driver close().  No close should allow a process
>to wait forever on a event that may not come.  Signals (kill -9) are
>delivered when a process in kernel mode re-enters user mode.  However,
>you process is waiting in kernel mode and won't get those signals til
>its done: NEVER! (or until the long sought interrupt allows it's WCHAN
>to go again.

Close, but not quite. It depends on the priority of the process during
the sleep, and what the driver does with the return value. If the
priority is less than PZERO, nothing happens, the sleep continues to
sleep, and all is as you note above; this corresponds to what is called
a "short term disk wait", and is usually used for events that are
expected with some high probability to happen quickly, or times where
cleaning up after an abort is so messy that it cannot be faced.

If the sleep priority is above PZERO, the sleep() will return an error
corresponding to "I was interrupted!". The device driver is then counted
on to clean up, abort whatever it was doing (or set up for a later
completion), and report error status if any to its caller. This
situation corresponds to longer term sleeps, like reading from a socket,
tty, or some other "slow" device.

Note that all processes that are sleeping have a WCHAN, that is how they
are woken up; if a signal is delivered to a process, it is woken up
independent of the value of its WCHAN.
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb