Xref: utzoo comp.unix.questions:7032 comp.unix.wizards:8519 comp.unix.microport:644 Path: utzoo!attcan!uunet!husc6!mailrus!ames!nrl-cmf!cmcl2!beta!unm-la!unmvax!turing.UNM.EDU!mike From: mike@turing.UNM.EDU (Michael I. Bushnell) Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.microport Subject: Re: Trouble killing processes in SysV/AT Message-ID: <1037@unmvax.unm.edu> Date: 9 May 88 07:52:44 GMT References: <3950@killer.UUCP> <3951@killer.UUCP> <216@obie.UUCP> <52288@sun.uucp> <6832@swan.ulowell.edu> Sender: news@unmvax.unm.edu Reply-To: mike@turing.UNM.EDU.UUCP (Michael I. Bushnell) Organization: University of New Mexico, Albuquerque Lines: 40 In article <6832@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes: [ Recants story about "It wouldn't die!" process...] >Would a program that does the following get rid of the process? > >1: Gets the process' proc struct from the kernel. >2: Changes fields like the status, priority, cpu usage, wchan, exit status > and maybe others so the kernel will have good reason to terminate the > process. >3: Writes the new struct back out (open /dev/mem for write, lseek, write). > >If something along these lines would work, it should carry over to most >unixes since they all should have the same or similar fields in the proc >struct. Ack! no! The whole reason for a sleep that cannot be interrupted is because the process has some kernel data structure locked. If you fake it to get the process killed, then the inode, text entry, whatever, will remain locked, and you can't ever get at it again. You could, perhaps, make your program even smarter, and have it figure out just what things were locked and unlock them, but remember, they may be partially modified, and fixing them makes this an even more daunting prospect. The *real* solution is to fix the bug in the kernel. Failing that, you are, well, hosed. -- N u m q u a m G l o r i a D e o Michael I. Bushnell HASA - "A" division 14308 Skyline Rd NE Computer Science Dept. Albuquerque, NM 87123 OR Farris Engineering Ctr. OR University of New Mexico mike@turing.unm.edu Albuquerque, NM 87131 {ucbvax,gatech}!unmvax!turing.unm.edu!mike