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 -+