Path: utzoo!attcan!uunet!seismo!ukma!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!bu.edu!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.unix.questions
Subject: Re: Killing the correct process
Message-ID: <5405@buengc.BU.EDU>
Date: 20 Feb 90 16:37:55 GMT
References: <22332@adm.BRL.MIL> <5312@star.cs.vu.nl> <1212@root44.co.uk> <5382@buengc.BU.EDU> <5615@star.cs.vu.nl>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.unix.questions
Organization: Boston Univ. Col. of Eng.
Lines: 47

In article <5615@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>In article <5382@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes:
>>what happens if the command has already exited
>>and some other process (possibly on another processor) has 
>>begun with the same pid?
>
>Possible if your `$command' has been running for a *long* time and/or new
>processes have come and gone like crazy in the meantime...  Normally it
>takes a few days for the pid to wrap around;

I'm talking about timing-out someone's login, possibly 12-20 hours
after the killer-process has been started.  Plenty of time.

>conventionally MAXPID is 30,000.  This value may have to be raised.

It's suspiciously low.  I can live with it, though, as cave-sysadmins
have had to do since the dawn of Unix.

I've got another idea, though, which is rather specific to this
problem.  Basically, I'm writing Yet Another Access Scheduler,
implementing it as a shell-wrapper to be placed as a user's
default-shell in /etc/passwd.  There's a dichotomy where the
decision is to be made whether to fork-and-exec the process-killer
(which then sleep()'s until it's time to kick the user off) and
exec the shell, or to fork-and-exec the shell and exec the killer.

So, if I fork the shell, it becomes the killer's child, and the killer
will get SIGCLD if the shell is exited.  If I do it the other way,
I run the risk of zapping some other guy.

I'll have to balance that fact against the three reasons I've
switched this flow-of-control three times already, but it's
somewhat stronger than the others, which involved convenience of I/O...

(BTW, the killer has to run suid-root, so the user can't kill it first,
so respecting interrupts is out.)

>>	system("ps -l##### > /tmp/foo"); /* ##### is the pid */

>How about `fp = popen("ps -l#####", "r")'?

Alas, popen() ain't ANSI, but who am I kidding?  Good idea.

				--Blair
				  "I wonder if Stephen King has
				   this sort of plotting trouble
				   with his killers..."