Troubleshooting
Problem
The cron daemon is not running jobs at their scheduled time. Jobs might run late, or not at all.
Cause
Check the cron log /var/adm/cron/log to see if there are any errors or other messages around the time the jobs should run.
If you see messages like this:
! c queue max run limit reached Fri Sep 20 13:15:00 2013
! rescheduling a cron job Fri Sep 20 13:15:00 2013
The reason the jobs are not running is because there are too many simultaneous jobs at the time the daemon tries to run a new job.
The cron daemon has a limit of how many jobs it can run simultaneously. By default it is 100 jobs. If a new job is scheduled to run, and the limit has already been reached, the job will be rescheduled at a later time (the default is 60 seconds later). Both the number of jobs and wait time are configured in the file /var/adm/cron/queuedefs.
If it is unusual for cron to be running so many jobs, you can check the process table to view the jobs cron has created. These jobs will have parent process id (PPID) of the cron daemon.
$ ps -ef@ | grep cron | grep -v grep
Global root 4653234 1 0 Sep 28 - 0:03 /usr/sbin/cron
It is sometimes helpful to view the processes and their parents in a tree format. This way we can see what jobs the cron daemon is currently running and what child processes those jobs may have created. You can use the "ps -T PID" command to see the process tree.
$ ps -T 2097204
PID TTY TIME CMD
2097204 - 0:33 cron
17760598 - 0:00 \--ksh
18153488 - 0:16 \--find
In the example above the cron daemon has 1 child job, which is a shell, and that shell (possibly running a script) is running the "find" command. This would count as 1 direct descendant job from cron.
If you find many of the same jobs stuck, there might be a problem with the script or command being run. The command or script should be checked from a shell prompt to see if it completes successfully.
If the large number of jobs are naturally occurring as a result of increased workload on the system, you may need to change the values in the /var/adm/cron/queuedefs file and increase them from their defaults. This file defines the event types and their properties.
To do this, add an entry to the bottom of the /var/adm/cron/queuedefs file using an editor such as vi. The entry should have the form:
For example:
c.200j2n60w
This example would set the cron queue to a maximum of 200 jobs, with a nice value of 2, and a wait time of 60 seconds.
It is not necessary to restart cron after modifying the queuedefs file, it will be automatically checked by cron's event loop.
If you see messages like this:
! c queue max run limit reached Fri Sep 20 13:15:00 2013
! rescheduling a cron job Fri Sep 20 13:15:00 2013
The reason the jobs are not running is because there are too many simultaneous jobs at the time the daemon tries to run a new job.
The cron daemon has a limit of how many jobs it can run simultaneously. By default it is 100 jobs. If a new job is scheduled to run, and the limit has already been reached, the job will be rescheduled at a later time (the default is 60 seconds later). Both the number of jobs and wait time are configured in the file /var/adm/cron/queuedefs.
If it is unusual for cron to be running so many jobs, you can check the process table to view the jobs cron has created. These jobs will have parent process id (PPID) of the cron daemon.
$ ps -ef@ | grep cron | grep -v grep
Global root 4653234 1 0 Sep 28 - 0:03 /usr/sbin/cron
It is sometimes helpful to view the processes and their parents in a tree format. This way we can see what jobs the cron daemon is currently running and what child processes those jobs may have created. You can use the "ps -T PID" command to see the process tree.
$ ps -T 2097204
PID TTY TIME CMD
2097204 - 0:33 cron
17760598 - 0:00 \--ksh
18153488 - 0:16 \--find
In the example above the cron daemon has 1 child job, which is a shell, and that shell (possibly running a script) is running the "find" command. This would count as 1 direct descendant job from cron.
If you find many of the same jobs stuck, there might be a problem with the script or command being run. The command or script should be checked from a shell prompt to see if it completes successfully.
If the large number of jobs are naturally occurring as a result of increased workload on the system, you may need to change the values in the /var/adm/cron/queuedefs file and increase them from their defaults. This file defines the event types and their properties.
To do this, add an entry to the bottom of the /var/adm/cron/queuedefs file using an editor such as vi. The entry should have the form:
- c.50j20n60w
c. = The "c" or cron queue, followed by a period separator.
Nj = The maximum number of jobs to be run simultaneously by cron, followed by the letter "j".
Nn = The "nice" value of the jobs to be run (default is 2), followed by the letter "n".
Nw = The time a job has to wait until the next attempt to run it, followed by the letter "w".
Nj = The maximum number of jobs to be run simultaneously by cron, followed by the letter "j".
Nn = The "nice" value of the jobs to be run (default is 2), followed by the letter "n".
Nw = The time a job has to wait until the next attempt to run it, followed by the letter "w".
For example:
c.200j2n60w
This example would set the cron queue to a maximum of 200 jobs, with a nice value of 2, and a wait time of 60 seconds.
It is not necessary to restart cron after modifying the queuedefs file, it will be automatically checked by cron's event loop.
| SUPPORT |
|---|
|
If you require more assistance, use the following step-by-step instructions to contact IBM to open a case for software with an active and valid support contract. 1. Document (or collect screen captures of) all symptoms, errors, and messages related to your issue. 2. Capture any logs or data relevant to the situation. 3. Contact IBM to open a case: -For electronic support, see the IBM Support Community: Click your country and use the Software phone number listed in the Contact information section. 4. Provide a clear, concise description of the issue. - See: Working with IBM AIX Support: Describing the problem. 5. Collect a system snap with cron data. # snap -r (removes previous snap data)
# snap -aZ (excludes system dump)
# tar -cvf /tmp/ibmsupt/testcase/cron.tar -C /var adm/cron spool/cron -C /etc cronlog.conf
# ls -al /usr/sbin/cron /usr/bin/crontab /usr/bin/at > /tmp/ibmsupt/testcase/cronfiles.ls 6. Prepare the snap for upload.
# snap -c (Compress snap)
Rename file to associate with your case
For AIX 7.2:
# mv /tmp/ibmsupt/snap.pax.Z /tmp/ibmsupt/yourcase#.snap.pax.Z For AIX 7.3:
# mv /tmp/ibmsupt/snap.pax.gz /tmp/ibmsupt/yourcase#.snap.pax.gz 7. Upload all of the details and data for your case.
RECOMMENDED:
a) Attach to your case
b) Upload to the Enhanced Customer Data Repository (ECuRep)
ADDITIONAL OPTIONS:
c) Blue Diamond customer data uploads (US only)
|
Related Information
[{"Product":{"code":"SWG10","label":"AIX"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Not Applicable","Platform":[{"code":"PF002","label":"AIX"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]
Was this topic helpful?
Document Information
Modified date:
10 June 2024
UID
isg3T1020382