Knowledge Base

Cronjobs on the Academic Computing Cluster

Overview

The Reading Academic Computing Cluster (RACC2) provides a dedicated cron-job node. This means you can schedule recurring tasks in the same environment used by other research computing applications. If a command works on a login node, it will also work on the cronjob node — including the ability to submit batch jobs. However, note that any submitted batch job may still wait in the scheduler queue, just like any other batch job.

This guide offers a concise introduction to using cron on RACC2. It is not a comprehensive tutorial — for that, many excellent resources are available elsewhere online.

 

Getting started

1. Connect to the cron-job node

ssh <username>@racc2-apps.act.rdg.ac.uk

2. Manage your crontab

  • To edit your crontab (the default editor is vi):

crontab -e

  • To list your cron entries:

crontab -l

  • To remove all your cron jobs:

crontab -r
⚠️ Be careful: there is no backup — use this only if you’re sure.

 

Recommended workflow (safer than editing directly)

Instead of editing the live crontab directly, we recommend:

  1. Create a text file in your home directory (for example, crontab.txt).

  2. Add all the cron entries there.

  3. Install the cron file with:

crontab crontab.txt

This workflow helps avoid accidental overwrites or deletion.

 

Example cron entries

  • Simple message at 17:30 every day

30 17 * * * /usr/bin/echo It\'s `/usr/bin/date +\%R`. Time to go home!

Running this job every day sends you an email with the output. Note that we need to escape some special characters.

 

  • Avoid frequent email by redirecting output

If your job generates a lot of output, you can redirect it to a log file:

*/5 * * * * script.sh >> $HOME/cronjob_outputs/output.log

The above job, runs every 5 minutes. Use > to overwrite the log each run, or >> to append. By default, cron sends standard error via email. If you want to combine stdout and stderr:

*/5 * * * * script.sh >> $HOME/cronjob_outputs/output.log 2>&1

Or, to discard all output entirely:

*/5 * * * * a_script_producing_a_lot_of_unwanted_output.sh > /dev/null 2>&1

 

  • Disable all cron email

Add this line at the top of your crontab:

MAILTO=""

 

Environment & paths

Cron jobs run in a minimal environment. In particular:

  • Standard environment variables (PATH, user profile config, etc.) may not be set.

  • Always use absolute paths for commands and scripts.

  • If your script depends on environment variables (e.g. paths, virtual environments, modules), it’s better to define them explicitly rather than relying on sourcing your shell profile.

Example (less recommended):

*/5 * * * * . $HOME/.bashrc; . $HOME/profile; /path/to/your/script.sh >> $HOME/cronjob_outputs/output.log 2>&1

Better:
Make a script that defines exactly what it needs, with full paths — this reduces the risk of failures if your profile changes. You can also combine multiple commands in one cron job by separating them with semicolons.

 

Good practices & cautions

  • Don’t rely on cron emails for output — redirect to log files or /dev/null if not needed.

  • Define your environment explicitly: avoid sourcing broad profile scripts.

  • Make sure your scripts have proper permissions and are owned by you.

  • Log and audit cron jobs: keep a record of what runs when and why. That helps with maintenance and troubleshooting.

  • Be mindful of cluster resources — if your cron job submits batch tasks, treat them like any other cluster job (they may queue, consume compute resources, etc.).

DTS Status Page
Drop-in Sessions

ACT services access flow

News
Suggest Content…
Click here and let us know!

Related articles

Transferring files to and from Linux storage

NAG library

ssh iconExternally visible ssh server – arc-ssh

NX authorization code

Recover a file on research storage

Using R and R Studio on RACC

ssh iconAccess to ACT Servers via an SSH Client

Running Matlab Scripts as Batch Jobs

Python on the Academic Computing Cluster

Changing your current group ID during a login session