kevin@cscnj (Kevin Walsh) (11/21/90)
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
craig@veritas.uucp (Craig Harmer) (11/28/90)
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 >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@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]
dcm@moria.UUCP (David C. Miller) (12/07/90)
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