Trouble killing processes in SysV/AT

Michael I. Bushnell mike at turing.UNM.EDU
Mon May 9 17:52:44 AEST 1988


In article <6832 at swan.ulowell.edu> arosen at 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 at turing.unm.edu				Albuquerque, NM  87131
{ucbvax,gatech}!unmvax!turing.unm.edu!mike



More information about the Comp.unix.microport mailing list