Xref: utzoo comp.unix.questions:6917 comp.unix.wizards:8340 comp.unix.microport:610
Path: utzoo!mnetor!uunet!pdn!boake2!jc3b21!rac
From: rac@jc3b21.UUCP (Roger A. Cornelius)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport
Subject: Re: Trouble killing processes in SysV/AT
Message-ID: <379@jc3b21.UUCP>
Date: 8 May 88 18:06:40 GMT
References: <3950@killer.UUCP> <3951@killer.UUCP> <3967@killer.UUCP>
Organization: St. Petersburg Jr. College, FL
Lines: 29
Summary: we have this problem on Altos xenix v3 also

In article <3967@killer.UUCP>, richardh@killer.UUCP (Richard Hargrove) 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?
> > 
> > I have encountered this a number of times, where it would be impossible
> > even for root to kill a process; 
> 
> Wolf,
> 
> While I've never seen this under Microport SYS V/AT, I have seen it under
> Intel Xenix 3.4 (SYS III based). Like you, I was amazed when the command

We have this problem on our Altos using xenix 3.3a1.  The only way I've found
to free the terminal after this happens is to either re-boot, or null out the
/etc/utmp file (this fools the system into thinking no-one is logged on), so
I can disable and re-enable the terminal.  The latter is better than telling
15-20 users they have to log off while we do a shutdown.  

Does anyone know what problems this could cause (besides 'who' not returning
anything)?  And wouldn't writing a program that removes the entry for the
locked terminal from /etc/utmp work as well?  Or maybe there's a better way?

Roger Cornelius
-- 
                +---------- Roger Cornelius -----------+
                |            (813)347-4399             |
                | ...gatech!codas!usfvax2!jc3b21!rac   |
                +-   ...gatech!usfvax2!jc3b21!rac     -+