Xref: utzoo comp.unix.questions:6902 comp.unix.wizards:8314 comp.unix.microport:602 Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport Subject: Re: Trouble killing processes in SysV/AT Message-ID: <52379@sun.uucp> Date: 7 May 88 03:04:36 GMT References: <3950@killer.UUCP> <3951@killer.UUCP> <216@obie.UUCP> <52288@sun.uucp> <6832@swan.ulowell.edu> Sender: news@sun.uucp Lines: 23 > On a Sequent Balance 21K with 6 processors, we recently had a user with a > program that failed to exit properly. It seemed to get stuck when it tried > to exit. ... > > Would a program that does the following get rid of the process? >Yes, but it also might get rid of your system as well. As I said, in many cases this sort of half-dead process is caused by something such as a driver blocking non-"interruptably" forever while doing a "close". The driver might well have a reason why it *didn't* want to be interrupted by a signal; it might be holding on to some system resource, for example, and be unwilling to be interrupted without having a chance to release that resource. Kicking the process's priority above PZERO, so that you can terminate it with a signal, might not be a good idea. (Also, I'm not certain what happens if you send a signal to a process that's in the middle of "exit" blocked on a "close"; it might not unjam the process.) It may be that the process doesn't exit properly due to an OS bug. If so, you should try to get it fixed; if, in the interim, you want a workaround and plan to dink with the process's process table entry, note that this is intrinsically very dangerous and be prepared to wedge your system well and truly if you try to do this.