sohail@terak.UUCP (10/10/84)
We have started to notice a problem with some
people's login csh being reniced. Since we always
have a few processes running, these people's terminal
appears to be dead.
By reniceing the csh to 0, the terminal becomes alive
again, and renice reports the old priority as 19.
Is there some thing in 4.1 bsd that renices people when
the system load gets too high?
or
do we have a malicious user who is fiddling with people's
priority. (I once looked thru lastcomm, and found that no
one had executed the renice command.)
Look forward to any info on the subject
sohail
--
Sohail Hussain
uucp: ...{decvax,hao,ihnp4,seismo}!noao!terak!sohail
phone: 602 998 4800
us mail: Terak Corporation, 14151 N 76th street, Scottsdale, AZ 85260sater@tjalk.UUCP (Hans van Staveren) (10/12/84)
A long time ago I also noticed this problem, I am not sure however that it was the csh that behaved like this. I confess having used the csh once but I guess the crime has aged now so people can't hold it against me. Anyway, you probably don't have a malicious user, but a wandering bug. -- Hans van Staveren, Vrije Universiteit Amsterdam ..!mcvax!vu44!sater
jdb@mordor.UUCP (John Bruner) (10/12/84)
This may or may not be related to the problem posed in <170@terak>, but it is a bug in all of the versions of "csh" I've seen (3BSD, 4BSD, 4.1BSD, 4.2BSD). The C shell is supposed to interpret the command % nice +n as a directive to change its own "niceness" to "n" (where "n" is 4 by default). However, the sequence that it uses to do this (in "sh.time.c", routine donice()) is [essentially] nice(20); nice(-10); nice(4); Thus, if you are "root" your "nice" is raised by 20, lowered by 10, and then raised by 4. Assuming that you started at 0 you are now at 13 (since it "pegs" at 19). If you aren't lucky enough to be "root", your "nice" is raised by 20, then it is raised by 4 more (negative "nice" requests are ignored for non-super-users). Thus, if you started at 0 you are now at 19. The reason for this lossage is the fact that nice() originally was absolute (e.g. "nice(4)" set your niceness to 4), but now (since V7) it is relative. The solution depends upon the version of UNIX you are running. On 4.2BSD nice() is just a subroutine and you can replace the sequence of calls to it with a single setpriority(). I'm not sure that there is a correct solution on other versions of UNIX (except V6, of course) unless your version of nice() returns the current "niceness". In any event, you should remove the extraneous "nice(20); nice(10);" (which would be wrong even if ordinary mortals were allowed to reduce their "niceness"). I'll resist the temptation to flame about the syntax of "csh"'s "nice" versus "/bin/nice". -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
anton@ucbvax.ARPA (Jeff Anton) (10/13/84)
If I remember 4.1 correctly it will move the nice of a process from 0 to +4 after 10 cpu minutes. This only applies to non-root and nice = 0 processes. Csh however has a bug in the way it handles the 'nice' internal command. Csh attempts to set the nice absolutely by doing the nice +40 then nice -(20-resultnice). This however, fails if you are not root and will set your shell to nice +19 (The real maximum). The fix is pretty easy. You should go into csh source and change these nices into a call to the new setpriority. (I think it's in 4.1) Disclaimer: I don't work on BSD, I just know a few pieces of it. (bugs) Jeff Anton anton@berkeley.arpa ucbvax!anton
guy@rlgvax.UUCP (Guy Harris) (10/13/84)
> We have started to notice a problem with some > people's login csh being reniced. Since we always > have a few processes running, these people's terminal > appears to be dead. > > By reniceing the csh to 0, the terminal becomes alive > again, and renice reports the old priority as 19. > > Is there some thing in 4.1 bsd that renices people when > the system load gets too high? In 4.2BSD, the following code appears in "kern_clock.c": /* * Check to see if process has accumulated * more than 10 minutes of user time. If so * reduce priority to give others a chance. */ if (p->p_uid && p->p_nice == NZERO && u.u_ru.ru_utime.tv_sec > 10 * 60) { p->p_nice = NZERO+4; (void) setpri(p); p->p_pri = p->p_usrpri; } so if a process accumulates enough CPU time, the system decides it's had enough favorable treatment and it's time to get tough with it. I seem to remember something like this also being in 4.1BSD, so that's what may be happening. Check "clock.c" in the kernel source. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
mjl@ritcv.UUCP (Mike Lutz) (10/14/84)
The problem Guy Harris mentioned about an 'automatic' renice is indeed
in 4.1bsd. We got bitten by this when some users of a spreadsheet
package would suddenly have their terminal locked up. Since one of
them was the department head, we quickly located and fixed the kernel
clock routine code.
Note that the renicing fix is a temporary measure. The next time the
process is running and the clock goes tick, down goes the priority
again.
--
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {allegra,seismo}!rochester!ritcv!mjl
ARPA: ritcv!mjl@Rochester.ARPAchuqui@nsc.UUCP (Zonker T. Chuqui) (10/15/84)
> Look forward to any info on the subject > By reniceing the csh to 0, the terminal becomes alive > again, and renice reports the old priority as 19. > Is there some thing in 4.1 bsd that renices people when > the system load gets too high? > or do we have a malicious user who is fiddling with people's > priority. (I once looked thru lastcomm, and found that no > one had executed the renice command.) It looks like a malicious user. The renice code, unless it's been munged, only goes to 4, not 19. the only way you'll nice a process to 19 is with human intervention. They don't need to use the renice command, there is a system call they can write into their own program to do it. Note that this user (unless he is smart enough to have figured out a way around it) much as root privileges to do this on the fly. Tracking someone doing this down is difficult at best. Brute force searches through source files is a start, but if he HAS broken root he's probably smart enough to hide it (if you've given him root and he did this, cut out his tongue for me....). You could instrument the setpriority() system call (that is 4.2-- I don't know if the name changes) to log to the console things like the uid of the person calling it when it us used on a process other than itself. If /dev/kmem is writable, I'd change that immediately-- someone may have figured out a way to change the values in someone's u. in there. sigh. chuq -- From the Department of Bistromatics: Chuq Von Rospach {cbosgd,decwrl,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA How about 'reason for living?'
dce@hammer.UUCP (David Elliott) (10/15/84)
> We have started to notice a problem with some > people's login csh being reniced. Since we always > have a few processes running, these people's terminal > appears to be dead. > > By reniceing the csh to 0, the terminal becomes alive > again, and renice reports the old priority as 19. > > Is there some thing in 4.1 bsd that renices people when > the system load gets too high? Another problem (besides the kernel renicing processes) is the csh builtin command `nice'. If you look at the documentation, you will see that `nice' with no arguments claims to set the nice of the current shell to 4. The code that attempts to do this does a nice(20), a nice(-10), and a nice(4) (supposedly, this changes the nice to the maximum, back to 0, and then to 4), but if you aren't the superuser, this sets the nice to 19 and that's all. (Does anyone know why this would have worked at some time?) It is possible that someone inadvertently typed `nice' with no arguments, or that you have a prankster going around typing `nice' on people's terminals without them knowing. David
ron@wjvax.UUCP (10/24/84)
From: dce@hammer.UUCP (David Elliott) Newsgroups: net.unix-wizards,net.bugs.4bsd Subject: Re: automatic renice in 4.1 bsd? Another problem (besides the kernel renicing processes) is the csh builtin command `nice'. If you look at the documentation, you will see that `nice' with no arguments claims to set the nice of the current shell to 4. The code that attempts to do this does a nice(20), a nice(-10), and a nice(4) (supposedly, this changes the nice to the maximum, back to 0, and then to 4), but if you aren't the superuser, this sets the nice to 19 and that's all. (Does anyone know why this would have worked at some time?) **** Well, when we were running U*IX on our 11/23, normal mortals COULD nice to minus numbers. In fact, when you had the machine to yourself you could do a nice --40 and watch your program whizz right along. Under these circumstances the csh would have no problem setting a priority of 4. Perhaps this "feature" of 4.1 is left over from the old 11/23 days? -- "Trivia is important." Ron Christian (syntax bug) Watkins-Johnson Co. San Jose, Calif. (...ios!wjvax!ron)