The Reading Academic Computing Cluster (RACC) has now a login node which is dedicated for running cronjobs. We have made the cronjob virtual machine (VM) a part of the RACC to allow to run cronjobs in the same environment as other research computing applications. If a command works on a login node, it should also work on the cronjob node. As the cronjob machine is a cluster login node, cronjobs can be used to submit batch jobs if needed. However, there is no guarantee such batch jobs will run right away, they might wait in the queue as any other batch job would.
This short document is not comprehensive. Many good crontab tutorials are already available online. Here, it is just a collection of tips we think are relevant for the UoR crontab users.
To use the crontabs node you need to connect to racc-crontabs.act.rdg.ac.uk using the following command:
ssh <user name>@racc-crontabs.act.rdg.ac.uk
To edit the crontab in your favorite text editor (by default it is vi) , you type crontab -e. If you just want to list the crontab entries, use crontab -l. All installed cronjobs can be removed with one command crontab -r . Careful! ‘r’ is right next to ‘e’ (i.e. the edit flag) on the keyboard, and here there is no backup! To not risk losing work because of a simple typing error we will not edit crontab directly, we will rather store the cronjobs in a text file in the home directory. Let’s call it crontab.txt.
To create an example cronjob, our crontab.txt contains one line:
30 17 * * * /usr/bin/echo It\’s `/usr/bin/date +\%R`. Time to go home!
Note that we need to escape some special characters. Now, we can install this cron table file by running
Cron emails to you the ouput from cronjobs, and in this example, everyday, at 5:30 you will receive a friendly email.
Typically users do not want to receive emails from every cron job they run. The following job, which runs every 5 minutes, has the standard output redirected to a file:
*/5 * * * * a_script_producing_a_lot_of_output.sh >> $HOME/cronjob_outputs/my_first_cronjobs_output.log
‘>>’ redirection appends the text at the end of the file, ‘>’ would just overwrite the file, such that only the output from the last cronjob run would be saved. Here, in case of error, the standard error stream will still be sent to the user by email. If such emails are not wanted, the standard error can be redirected to standard output:
*/5 * * * * a_script_writing_to_stderr.sh >> $HOME/cronjob_outputs/my_first_cronjobs_output.log 2>&1
You can also globally disable emails for all your cronjobs by adding
in the first line of the crontab.
If you want to discard all the output, it can be redirected to the system’s bit bucket /dev/null:
*/5 * * * * a_script_producing_a_lot_of_unwanted_output.sh > /dev/null 2>&1
Cron runs the jobs in an empty or almost empty environment. This is the reason why in the previous examples above we had to specify the full path to the commands like ‘echo’ or ‘date’. To have the jobs running in the environment similar to interactive shell environment, some users source their profile scripts before running their cronjob task:
*/5 * * * * . $HOME/.bashrc; . $HOME/profile; a_script_which_needs_all_my_environmental_variables.sh >> $HOME/cronjob_outputs/my_second_cronjobs_output.log 2>&1
It does the job, however it might be dangerous. The cronjob might start failing after changes are made in the profile scripts. Writing scripts which define all the variables they need and do not depend on the profile scripts is therefore recommended.
You can run multiple commands as a single cronjob by separating them with semicolons.