Cron facility can be used to schedule regularly occurring commands or scripts. Users can submit cron jobs by adding an entry to their respective crontabs located in /var/spool/cron/crontabs directory and stored as their login name. Below are few of the troubleshooting tips and best practices which can be helpful in many cases.
Important cron files :
The important files related cron are :
/etc/cron.d/cron.allow
— File containing usernames that have permission to submit cronjobs
/etc/cron.d/cron.deny
— File containing usernames that don’t have permission to submit cronjobs
/var/cron/log
— Cron Log file
/var/spool/cron/crontabs
— Directory containing individual crontab files of all users.
How to edit a crontab :
The best way to edit a crontab is using the command crontab -e. Another way of doing it is :
1. su to the user whose cron you want to change
2. crontab -l > file [ copy the crontab to a file ].
3. vi file [ make changes to the file as per your need ]
4. crontab file [ this makes the “file” as new crontab ]
There is no need to restart the cron daemon after this.
Note : If by mistake you simple run only crontab command, don’t try to come out by typing CTRL+D as it will remove all the entries in the crontab file. Use CTRL+C to come out of the crontab command.
Check whether cron daemon is running
Check if the cron daemon is running in the system [prior to solaris 10] :
# ps -ef |grep cron
To start or stop cron daemon use:
# /etc/init.d/cron [stop|start]
In case of Solaris 10, check the for the cron service status :
# svcs -p svc:/system/cron
To make sure cron jobs are running properly, add below entry in the crontab.
* * * * * date > /dev/console
This will print the date every minute to the console. You can also use pts terminal you are working on, if you don’t have the access to console.
Controlling access to crontab :
– The file /etc/cron.d/cron.allow can be used to allow users to submit cron jobs.
– If the cron.allow file is not present cron checks /etc/cron.d/cron.deny file to see which users are not allowed to submit cron jobs.
– If a user is present in both the files, the cron daemon checks the cron.allow file first and ignores the cron.deny file.
– If both files are missing only root can run the jobs.
Check permission and path to the script :
Seems silly, but I have seen many people doing this mistake of not giving executable permissions to the script they want to run from cron.
# chmod u+x /path/to/script
Also make sure that the cron entry has absolute path to the script and also to the shell used by the script:
* 5 * * * /bin/bash /path/to/script.sh
Check the cron logs :
Many a time the cron log file /var/cron/log clearly points out the issue in the cronjob. Check for the period in which the scripts should have run in the cron log. this would most probably point out the error in the cronjob.
Be careful when emptying a crontab :
If you delete all the cron jobs using crontab -e, the command crontab -l will still show all the cron jobs. this is because crontab -e does not know what to do with an empty crontab file. So it does not update any changes. The proper way to delete all the jobs from the crontab is :
# crontab -r
Check cron permissions
Sometimes you must have encountered an error “error in message queue open”. One of the reasons of this is a wrong permission to cron and crontab. The proper permissions of cron and crontab are :
# ls -l /usr/sbin/cron
-r-xr-xr-x 1 root sys 57420 Jan 22 2005 /usr/sbin/cron
# ls -l /usr/bin/crontab
-r-sr-xr-x 1 root bin 20336 Jan 22 2005 /usr/bin/crontab
Note the setuid permissions on crontab file.
‘crontab -e’ command returns a number and a ‘?’
Sometimes when you try to edit a crontab file using crontab -e command, it prints a number and a ‘?’. This is because by default the editor used by crontab -e command is the default solaris editor ‘ed’ and not vi editor. When ed starts up it prints the number of characters in the crontab file and does not have a prompt.
To avoid this, simple com out of the ed editor by typing q. Now set the EDITOR environmental variable to vi and run crontab -e again :
# EDITOR=vi
# export EDITOR
Password expired for a user :
Many a times cron jobs fail because the password has expired for the user owning the job. In that case you would see below error in the cron log file /var/cron/log :
Authentication token is no longer valid; new one required
CRON (oracle) ERROR: failed to open PAM security session: Success
CRON (oracle) ERROR: cannot set security context
The solution to this problem is to extend the password for the user :
# passwd -x 10 oracle
Redirection / special symbols and their meanings
It is good to know some of the redirection and special symbols being used when adding an entry to the crontab. Any mistake in using them may again lead to a cron job failure. An example of using these symbols in a cron job entry is :
0 5 * * * /bin/bash -l -c ‘export RAILS_ENV=my_env; cd /my_folder; ./script/script.rb 2>&1 > ./log/my_log.log’
Redirection file descriptors
There are 3 standard file descriptors :
1. stdin 0 – Standard input to the program.
2. stdout 1 – Standard output from the program.
3. stderr 2 – Standard error output from the program.
Normally stdin is from the keyboard and stdout and stderr goes to the terminal. But we can redirect it to a file. One of the most commonly used (and confusing) redirection is “2>&1″. It means take the standard error output from the command and send it to the same place where standard output is going.
Other than the most redirection symbols, there are many other symbols used while entering a cron job entry in the crontab :
;
Used to separate two commands on one line
&
Run the command in the background
&&
Run the following command only if the previous command completes successfully, (i.e., grep string file && cat file)
||
“Run the following command only if the previous command did not complete successfully, (i.e., grep string file || echo “”String not found””)”
( )
The command within the parentheses is executed in a subshell
‘
= single forward quote – Don’t assign any special meaning to any character within these quotations
Take the following character literally. Also used to “”escape”” a new-line character so that a user can continue a command on more than one line
” “
Allow variable and command substitution with these quotations
`command`
` = single back quote – Take the output of this command and substitute it as an argument on the command line
#
Everything following # until is a comment
