Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!masscomp!ocpt!tsdiag!moria!dcm
From: dcm@moria.UUCP (David C. Miller)
Newsgroups: comp.unix.internals
Subject: Re: Cron lowering nice value of jobs run
Keywords: ksh background processes
Message-ID: <387@moria.UUCP>
Date: 7 Dec 90 05:46:36 GMT
References: <1990Nov20.163139.9997@cscnj> <1990Nov28.055412.22357@veritas.uucp>
Organization: The Black Chasm
Lines: 41

In article <1990Nov20.163139.9997@cscnj> kevin@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@veritas.uucp> craig@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