Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site hslrswi.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!cernvax!hslrswi!robert
From: robert@hslrswi.UUCP (Robert Ward)
Newsgroups: net.sources.bugs
Subject: Re: SPS - a useful replacement for ps(1)  (but....)
Message-ID: <121@hslrswi.UUCP>
Date: Wed, 3-Jul-85 15:43:58 EDT
Article-I.D.: hslrswi.121
Posted: Wed Jul  3 15:43:58 1985
Date-Received: Sat, 6-Jul-85 10:21:15 EDT
Organization: Hasler AG, Bern, Switzerland
Lines: 28

Sean Casey (sean@ukma.UUCP) points out that sps runs at nice -20
and hence runs fast at the expense of other users. He even goes on
to point out that typing "sps adefgvwr >/dev/null &" can have pretty
dire consequences for everyone else.

Well, of course, he is absolutely right. Sps does renice itself not
just to go faster but also in an attempt to look at separate kernel data
structures before they are changed too much or become too inconsistent
with one another.  In practise, however, it doesn't seem to affect the
response time of sps too much whether it runs at nice -20 or nice 0.

One solution, suggested by Jeffrey Mogul, is to renice sps only for root.
This also means that sps need not be a setuid program.
Here is the diff for main.c -

26,28c26,29
< 	/* Renice as fast as possible for root (Suggested by Gregorio!mogul) */
< 	if ( !getuid() )
< 		(void)nice( -40 ) ;
---
> # ifndef TRACE
> 	(void)nice( -40 ) ;
> 	(void)setuid( getuid() ) ;
> # endif

Personally, I don't think it matters much either way.

(Robert Ward, Hasler AG, Belpstrasse 23, CH-3000 Bern 14, Switzerland).