Re: Request for HUP-ing Unix clients

Garance A Drosehn (gad@eclipse.its.rpi.edu)
Tue, 27 May 97 15:47:21 -0400


To my previous message, I have received many replies (mostly sent
directly to me) which all make the same suggestion in an attempt
to be helpful. Let me answer one such message to the list, before
I go nuts answering all the individuals...

> > I pretty much have to blow the process away as soon as someone
> > does log in, simply because these machines were bought for the
> > people who are logging in, and were not bought to run deschall
> > clients. So, when someone logs in I send a HUP signal to the
> > deschall client, and it politely goes away.
>
> No no no, just kill -STOP it.
> When the user logs out, kill -CONT it.

In any project like this, there are technical issues and political
issues. The above is a perfectly good technical answer. It is
completely useless when it comes to the specific political issues
of my environment.

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".
I do not have the time or inclination to try and prove to every
single one of those real users that the process is not effecting
them. The people who did buy the hardware would not be happy with
the phone calls, even if they were completely confident that my
technical answer was correct. I would not blame them for being
unhappy. I don't like getting phone calls either.

> Well thats not true now is it! init, update, gettys and all the
> rest, inetd, etc are all eating CPU.

Those are all running as root. Real users are used to ignoring
those. I am not going to run deschall as root. This makes it much
more obvious to real users. I am not going to expend any effort to
"hide" it from users. This is not a contest where I try to see
what I can get away with.

> Nice -19 deschall-client will effect the same thing.[*]
>
> (unless you are running Irix, apparently).

I'll give you three guesses what hardware I was running this on
over the weekend... :-)

> At -19 it will use negligible CPU. Will not bother the user. If
> the name of the process bothers the user, get creative. ;)

Before I got interested in this project, some of our students
setup deschall to run on on various lab machines (taking advantage
of an oversight in our login-checking -- they were not supposed to
be able to do this). *We*, as the computer center, did not notice
this until other real users started complaining about their work
being slowed down by some other user who was logged into the machine.

So, it *was* noticable to real users, even though the students
doing it were nicing the process as much as they could. This
was on both AIX and IRIX (and perhaps on some of our Solaris
machines, but I'm not sure about that).

> Are you subject to the stupidity that I have been as far as
> 'resource hogging' and the like? :)

Under the circumstances that I'm in, I would not call it stupidity.
These are simply the real-world constraints, and I don't even think
they are stupid constraints.

Now, I can also understand the real-world constraints of the people
volunteering their time to work on clients, so I do not expect them
to implement all of my suggestions... :-)

I *do* want to describe the issues for the list, so others who plan
similar distributed-computing projects would at least think of
these real-world constraints when they design their protocols and
servers. The deschall project is quite an impressive example of
voluntary collaboration, and I'm sure others will be interested in
the issues which come up in attempting such a collaboration. I
expect that those issues of large-scale collaboration will still
be of interest long after the novelty of having broken DES has
worn off.

---
Garance Alistair Drosehn     =     gad@eclipse.its.rpi.edu
Senior Systems Programmer        (MIME & NeXTmail capable)
Rensselaer Polytechnic Institute;           Troy NY    USA