Cron lowering nice value of jobs run
Craig Harmer
craig at veritas.uucp
Wed Nov 28 16:54:12 AEST 1990
In article <1990Nov20.163139.9997 at cscnj> kevin at cscnj (Kevin Walsh) writes:
>Does anyone out there know why cron starts up it's subshell(s) at a lower
>nice value than cron itself is running at? There also seems to be a difference
>in nice value between scripts/processes started via crontab using a cron table
>and by "at". The jobs run via the "at" program run with a lower nice value,
>and therefore higher priority, than those started from a cron table. Starting
>a process in background from a shell script which is run by a cron table seems
>to give the highest nice value (to the background process).
>
>I am curious as to why this is done since it does not seem to provide any real
>benefits and certainly no performance advantages in an application which makes
>considerable use of a cron table for periodic processing.
>
>Thanks, Kevin.
>--
>---------
>Kevin Walsh Computer Sciences Corporation Piscataway, NJ 08854
>..!rutgers.rutgers.edu!cscnj!kevin
apparently cron (in SVR4, at least) nices (see nice(2)) background
processes by 2 (by default). cron jobs should be less important
then whatever interactive stuff is being done, so this is reasonable.
if its a problem, you can always nice the process back up (if you're
running as root).
another possibility is that you're seeing a "feature" of the ksh
(which probably also occurs when ksh is used as a replacement for sh,
by invoking it by the name "sh"). ksh nices (see nice(1)) background
processes by 4, presumably because they're less interesting than foreground
processes. background processes started from shell scripts run via
ksh will get nice'd as well. this produced some interesting problems
on one system when we were starting the inet daemon from a shell script that
was executed by ksh.
--
{apple,pyramid,amdahl}!veritas!craig craig at hoser.veritas.com
(415) 626-6827 (h) (408) 433-5588 x220 (w)
[views expressed above shouldn't be taken as
Veritas' views, or your views or even as my views]
More information about the Comp.unix.internals
mailing list