Cron lowering nice value of jobs run

[David C. Miller]

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
>
>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.
>
>-- 
>---------
>Kevin Walsh  Computer Sciences Corporation  Piscataway, NJ  08854
>..!rutgers.rutgers.edu!cscnj!kevin

In article <1990Nov28.055412.22357 at veritas.uucp> craig at veritas.uucp (Craig Harmer) writes:
>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).

There is a file (/usr/lib/cron/queuedefs) that defines a couple
of tuneables for cron.  The default looks like this:

a.4j1n
b.2j2n90w

The fields are:

<Queue>.<number of jobs>j<nice value>n<second to wait for retrying>w

So, "a.4j1n" means for queue "a" (the at(1) job queue) it can start
4 concurrent jobs per user, with a nice of one.  There is no retry for
at(1) jobs.  The second entry gives the data for the crontab(1) queue.
2 concurrent jobs per user, a nice of 2, and wait 90 seconds before
trying again if fork(2) failed.

This goes back to SVR3 and maybe even SVR2.

Hope this helps.

David