How many jobs are in cron queues?

[Cameron Rooke]

Does anyone have a foolproof way of determining how many jobs are in the cron queues and what those jobs are? We have a situation where some cron jobs never exit due to application error and the cron queue limit is reached (set to max of 100 in the queuedefs file).

On 11.11, most of our cron jobs take the init process as the parent instead of cron, so a count of the cron PID doesn't work (jobs on 11.0 always had cron's PID as the parent). Also, not all jobs get logged properly to the cron log so a count of started versus finished jobs in the log is not accurate either.

It would be nice to know which queue they are in as well.

Any ideas?

[Siem Korteweg]

I tested with one running cronjob (HP-UX 11i), the process-ID was 987, the job started at 15:30.

# ls -l /var/spool/cron/tmp
total 0
-rw------- 1 root sys 0 Dec 1 15:30 croutPCAa00987

[Thierry Poels_1]

hi,

the previous trick is not foolproof, but will give you a good estimate. Temporary files are somtimes left behind.

How about checking /var/adm/cron/log for error messages about full queues??

BTW 100 for the cron queue is rather high, so I hope you have a neat sever over there. With a large queue you risk having the same job running mutliple times simultaneously.

regards,
Thierry.

[Bill Hassell]

The question is somewhat ambiguous. If you mean: what are the total number of entries in the submitted cron list, just count the non-empty, non-comment lines in all the cron files in /var/spool/cron/crontabs. If instead you are looking for the number of simultaneous jobs, then it will always be potentially inaccurate. For instance, dmesg - requires a fraction of a second to run so you'll likely never see it. You could run a cronjob (smiley face) to count the active jobs every minute, but the best way is to just read and map the cron logfile /var/adm/cron/log. This log provides an accurate account of each cronjob that was run, the start time, the command and the stop time. Since jobs overlap each other, you'll need a fair amount of scripting to sort this out and give a true picture of the cron load...but worth the time required to spot runaway or bad jobs.