Re: Request for HUP-ing Unix clients

Eating Before Swimming (mathboy@sizone.org)
Tue, 27 May 1997 21:16:16 -0400 (EDT)


then Andrew Sterian's all..
>
> Garance A Drosehn writes...

> > the real users to have *all* the resources of the machine. And,

> 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)

This is no good. A blank newly booted SGI with IRIX on it would NOT
have these services available. This would be extra for the users
to consider, and a pain for them to have to keep in mind if they want
to give away a slot in the process table, or not, as a 'favour' to
someone else. Then, when things hang on them and they have no clue
what it is, their code, those amazingly solid IRIX binaries or deschall,
they have to restart from scratch, and, guess what - first thing they'll
do it kill deschall and try it again. And theyll never know if the
fact that deschal ran for even a SECOND or two and was then stopped
or killed is causing the problem, yes, deschall post mortem. (I have
seen this with other servicesthings many times. Run one thing first
and even when it quits something else wont run again.)

So your solution is already flawed (as is my kill -STOP a concealingly
renamed deschal client).

> 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.

How many cycles does deschall get to run on your systems then? Does everone
kill it immediately at login? Are the machines busy often?

> 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.

This is not true. I remained unhappy because another user was running
a distributed process on all the boxes in the lab and I couldnt kill it.

But I didnt need to be. It was heavily niced, but this was 9 years ago
before I knew all the nuances of multitasking considerations in unix.
Had I and others who noticed all got the admins to kill it (which they
wouldnt have, already understanding how nice works (yes these were
admins of olde)), the student would have not got his work done,
and, by projection, no undertakings of multiprocessing would get very
far (as our machines were overused).

The only thing that WOULD have helped is if someone or some file or
something somewhere was around to EXPLAIN how nice works and how it was
not affecting my usage of the machine whatsoever. Me being able to kill
his process would not have been very helpful for him, nor for me when I
took that course and did the same thing a couple years later (had an
expectation of having an implimented system to kill everything in site
at login prevailed in the lab).

/kc

-- 
Ken Chase mathboy@sizone.org Sonic Interzone $free$ email/news Toronto Canada
------------------------------------------------------------------------------
Join the DES Challenge! Wake up the US Govt!   www.frii.com/~rcv/deschall.htm

NB:Only 16000 P200-months CPU req'd to recover 56-bit IBM alliance keys! ** U.S. EXPORT LAWS MAY NOT APPLY TO YOUR COUNTRY: DEVELOP YOUR NATIONS' OWN CRYPTO-EXPORT INDUSTRY! USE 2048bit KEYS FREELY! FLAUNT YOUR SOVEREIGNTY! **