Solaris 10 Queuedefs

Linux platforms have a very crude cron facility compared to Solaris and other enterprise Unix platforms. The Linux cron facility needs to be upgraded to support the concept of queue definitions.

In Solaris 10, for example, the number of concurrent jobs, their priority and rescheduling times are configurable via /etc/cron.d/queuedefs. In previous versions of Solaris, the number of concurrent jobs was hard-coded to 100 concurrent jobs.

The queuedefs file is read by the clock daemon, cron, and controls how jobs submitted using at, batch, and crontab are executed. Every job submitted by one of these commands is placed in a certain queue, and the behavior of these queues is defined by queuedefs.

Queues are designated by a single lower-case letter. The following queues have special significance:

  • a – at queue
  • b – batch queue
  • c – cron queue

For a given queue, queuedefs specifies the maximum number of jobs that may be executing at one time (njobs), the priority at which jobs will execute (nice), and the how long cron will wait between attempts to run a job (wait). If njobs jobs are already running in a given queue when a new job is scheduled to begin execution, cron will reschedule the job to execute wait seconds later.

Each line of queuedefs gives parameters for one queue. The line must begin with a letter designating a queue, followed by a period (.). This is followed by the numeric values for njobs, nice, and wait, followed by the letters j, n, and w respectively. The values must appear in this order, although a value and its corresponding letter may be omitted entirely, in which case a default value is used. The default values are njobs = 100, nice = 2, and wait = 60.

The value for nice is a hint to the kernel to modify the priority of a job. As with the nice and renice commands, a higher nice value results in a lower scheduling priority.

A typical queuedefs file might look like:


In the first example at is allowed to run twenty jobs at a time with a nice value of ten. Jobs will be rescheduled to run 60 seconds (the default value if not specified) later if there is no room in the run queue. In the second example, batch can run five jobs at a time with a nice value of fifteen, and a rescheduling period of 90 seconds. In the third example, cron can run 200 jobs at a time with a nice value of 10 and a rescheduling period of 30 seconds.

On a Solaris 10 system with lots of concurrent cron jobs, you may start seeing something like the following in /var/cron/log:

! c queue max run limit reached Thu April 23 12:25:16 2012

This indicates that cron attempting to start too many concurrent cjobs. You need to modify the cron queuedef entry to enable more concurrent jobs or modify the crontab entry to reduce the number of concurrent jobs.

Comments are closed.