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.wizards
mailing list