Trouble killing processes in SysV/AT

MFHorn arosen at eagle.ulowell.edu
Sat May 7 09:53:20 AEST 1988


In article <52288 at sun.uucp> guy at gorodish.Sun.COM (Guy Harris) writes:
>A *live* process that refuses to die, which is what was originally being
>discussed, is a different matter. A very common cause of this is a driver that
>blocks for a very long time - possibly forever - with a priority less than or
>equal to PZERO.

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.  The annoying thing was each time he ran it, we'd lose one of our
processors (whichever one tried to perform the exit).  Since the process was
in kernel mode, it couldn't receive any signals.  After it was run a few
times, the machine was 6 times slower than usual; we had to reboot.

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.

I've written programs that change a process' proc struct; it's proabably
not a good idea (you should be _very_ careful if you try it), but it
does work.  [it can be pretty fun.  "Ok, let's make this vi privileged..."]

I'd like people's opinions before I start trying to create some immortal
processes to nuke.

Andy Rosen           | arosen at hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031   | ulowell!arosen          |  learned how to make it
Lowell, Ma 01854     |                         |  talk" -Thunder Road
                   RD in '88 - The way it should be



More information about the Comp.unix.wizards mailing list