Killing the correct process

[Blair P. Houghton]

In article <5636 at star.cs.vu.nl> maart at cs.vu.nl (Maarten Litmaath) writes:
>In article <5405 at buengc.BU.EDU>,
>	bph at buengc.BU.EDU (Blair P. Houghton) writes:
>)...
>)I'm talking about timing-out someone's login, possibly 12-20 hours
>)after the killer-process has been started.  Plenty of time.
>
>I think you need a new system call like `killtree()' or `killsession()' to
>solve your problem completely:

Sending a kill -HUP to a login-shell in the console window
of a uVAX workstation Running Ultrix clobbers all of a
login's processes and cycles the X server.

I'm going to have to implement something to duplicate the
essential portions of the globalized .logout procedure
(we've got some buggy CAD sw that refuses to die unless
you've closed it carefully or kill -KILL'ed it.  Actually,
it's not so much buggy as it's poorly designed by some
less-than-proficient people at a UCalifornian school
that's rather well known for its software but must be eating
dirt due to these guys but that shall remain nameless...)

>-	you cannot kill all his processes, as you must leave background
>	processes and processes on other terminals alone

In _this_ case, I can justifiably kill all his processes,
and remote logins and backgrounded jobs are verboten as
well.  The scheduling is designed for lab purposes, and
excluding someone from the scheduling restriction is the
default.  Anyone with the right to run as a normal user
will get it.  It's only the great masses of students who
only need one piece of CAD software and a little email who
get scheduled.  The scheduler was designed to control lab
access, rather than to massage terminal usage.  Use of the
CPU is the important thing.

I may yet go looking for all processes with the user's pid
in them and "kill -f" them (I'll have to write an implementation
of the -f flag, though...:)

>-	process groups aren't the answer either

And it seems from the documentation that they would be... :-(

>Therefore there's a time window between determining which processes have to
>be killed, and actually killing them.  During this interval the user may have
>created new processes.

It's a matter of getting the right one and making sure it's
the same user.  Right now I'm checking to see that the pid
is running, that it's owned by the correct uid, on the same
tty, and has the same name (e.g., "-sh", "-csh", "-ksh",
etc.) as when the killer-program was started (i.e., at
login time.)

It's still a crap-shoot, but it's a crap-shoot with
probability of failure that has an *upper* bound of
1/30,000.  That is one in 30,000 times when the same
person has logged out and logged back in on the same
workstation on the same day.  Such a situation is not
too common in a big lab with tons of students and lots
of workstations.

So I'm reduced from perfection to sufficiency and a
balancing of the relative costs.  I can handle one in
30,000 users' getting angry.  I can't handle the eleven
professorial harangues per day when students can't get
into the lab on time...

				--Blair
				  "If you can't do it right, at
				   least be successful at it."