- Article Type: General
- Product: Aleph
- Product Version: 20, 21, 22, 23
A job which has an entry in the $alephe_tab/job_list file doesn't run.
Various. See Resolution and Additional Information below.
1. Make certain that the $alephe_tab/job_list entry (also editable via util e/16/1) is correct;
2. Restart the job daemon (util e/15/1) after any change to the job_list file
3. Make sure that the batch queue (the "lib_batch" process) of the library in which the job is supposed to run is active (util c/1)
Is there a log for the job in $alephe_scratch?
Yes: This means that the job ran, but may have failed for some reason. Examine the log to see why.
Does util c/1 for the library the job was supposed to run in show a lib_batch process?
No: Does util c/7 show that the job is queued up waiting to run? If so, you need to start the batch queue (util c/2).
Check the jobd.log file in $alephe_scratch. Is there a "Performing Jobs" line for this job at the expected time?
Yes: If it shows an error, the job_list entry needs to be corrected. If no error, that means the job was released. If the library's batch queue is running, this indicates a problem with the batch queue. Jobs submitted via GUI Services are also likely not running. See SKB 5672.
No (there is no "Performing Jobs" line)
Check the two-character Day value in column 1 of the job_list entry in job_list.conf to make certain that
today is marked with a "Y". (Note: the first day is Sunday; the last is Saturday.)
If it is and it's not seen in the jobd.log, it may be that the job daemon was not restarted after the change or that there's a problem with the job daemon. In either case, do util e/15/2 to kill the job daemon, util e/15/3 to confirm that it has been stopped, then util e/15/1 to restart it.
For version 21 installations using elib services: In the $alephe_root/aleph_start.private file there is the JOBD_STARTUP parameter. If it's equal to "N", the job daemon is not started by the aleph_startup script.
- Article last edited: 4/16/2014