Re: Request for HUP-ing Unix clients

Andrew Sterian (asterian@eecs.umich.edu)
Tue, 27 May 1997 16:43:53 -0400 (EDT)

Garance A Drosehn writes...
> I did not buy the hardware which I would like to run deschall on,
> and I feel it is completely within the rights of the people who
> did buy it to determine the rules for using that hardware. They
> would not mind the machines being used for something like descall
> when a lab is locked up and totally idle, but as soon as the "real
> users" show up then the people who bought the hardware would want
> the real users to have *all* the resources of the machine. And,
> perhaps more importantly, they want all the real users to be
> confident that all of the machine's resources are available to
> them.
>
> So, in a technical sense I could suspend the process, and the real
> users would not really be able to measure any effect of having that
> suspended process sitting there. However, they would *see* the
> process there, and they would call around asking that it be blown
> away "because the machine seems slower today than it did yesterday".

Let me describe to you the system we have here at the University of
Michigan. It is not perfect, but I think it satisfies most people
most of the time.

CAEN (our sysadmins, Computer Aided Engineering Network) provide
two programs on Unix workstations: babysit and rmproc.

'babysit' starts a process under a login monitor. The process is
automatically nice'd, and then when a user logs in to the workstation
(at the console, not via remote login) the 'babysit' program automatically
sends a STOP to its children. The children do remain resident in
memory, however.

After the user logs in, a message is sent to his xterm that indicates
that so-and-so's programs are running under babysit and they are not
taking up ANY CPU time.

The 'rmproc' program gives the console user control over all background
processes (except for system processes, of course). The 'rmproc' program
will let the user:
- re-nice the process to something lower (mainly for processes NOT
running under babysit)
- stop the process (if not already stopped by babysit)
- kill the process (even if it doesn't belong to the login user)

The important points of this implementation IMHO are:

1) CAEN endorses the 'babysit' and 'rmproc' tools so they do not appear
to be cracks or otherwise illegal to users. A program running under
'babysit' is "legitimate" in the eyes of users because they know
it will suspend itself when a console user logs in.

2) The user is notified at login time as to what background processes
are running under babysit. Thus, there is no "deception".

3) The login user has control over the entire machine via the 'rmproc'
program.

The 'rmproc' program is still used a bit too much in my opinion, as you
do get the effect of users really wanting control over the entire machine
(even if DESCHALL is using 0% CPU and a whopping 150K of RAM). I'd like
to see CAEN make more of an effort to explain this aspect (and about
virtual memory...if the 150K really is needed, DESCHALL will be swapped
out because it's stopped, etc.) Still, the users' illusion that they have
made great gains by killing DESCHALL is enough to keep everyone happy.

The bottom line: getting sysadmins to implement a sound policy on
running background programs (i.e., something like implementing babysit
and rmproc) will go a long way towards keeping everybody happy, not
only for DESCHALL but for the future as well.

Heck, you may even want to get sysadmins to contact CAEN and ask for
the above programs (http://www.engin.umich.edu/caen).

Andrew. asterian@umich.edu | Help crack DES in your computer's spare time!
----------------------------| http://www.frii.com/~rcv/deschall.htm
For the teddy bear who has |----------------------------------------------
everything, a person. | Me: http://www-personal.umich.edu/~asterian