Trouble killing processes in SysV/AT

Pete Holsberg pjh at mccc.UUCP
Sun May 1 01:05:30 AEST 1988


In article <468 at micropen> dave at micropen (David F. Carlson) writes:
...In article <3951 at killer.UUCP>, wnp at 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.

This happens frequently on my 3B2/400 when it gets into a deadly embrace
with my modem:  I cannot kill -9 any of the processes associated with
that port!  It takes toggling the modem's ON/OFF switch to break the
embrace.  Surely there must be a better way!  ??



More information about the Comp.unix.microport mailing list