Cron-Like Jobs

RCC does not currently support cron on any nodes. The reason for this is because cron jobs are tied to a specific machine. However, the system configuration expects that no permanent user data should be stored on a login or compute node. This allows a compute node or login node to be replaced, reinstalled, updated, etc. at any time with no impact to a user because there is no permanent data stored on a node. Supporting cron in this environment would likely lead to cron jobs being lost with no way to notify users.

It is possible to use Slurm to schedule periodic jobs but it will not be possible to have jobs run on a strict schedule like what is possible with cron.

Note

Due to the possibility of abuse you must email help@rcc.uchicago.edu and request access to submit cron-like jobs. These jobs are subject to strict scheduling limits and will be monitored for abuse.

An example submit file is cron.sbatch:

#!/bin/bash

# specify the time limit for the cron job
#SBATCH --time=00:00:10

# use cron.log and append to it
#SBATCH --output=cron.log
#SBATCH --open-mode=append

# the account, partition, and qos should not be changed
#SBATCH --account=cron-account
#SBATCH --partition=cron
#SBATCH --qos=cron

# Specify a valid cron string for the schedule
# this is daily at 5:05 AM
SCHEDULE='5 5 * * *'
# the following command is for illustration purpose
# a more useful command would be submitting another regular job
# sbatch --quiet regular_job.sbatch 
echo hello on $(hostname) at $(date)

# resubmit this script with --begin set to the next scheduled cron time
# next-cron-time is a script that parses a cron schedule string and returns
# the next execution time
sbatch --quiet --begin=$(next-cron-time "$SCHEDULE") cron.sbatch

This script just echoes the hostname and date but a more useful command would have been submitting another regular job. It is important to note that this script resubmits itself at the end of the script. We add the --begin with a specific cron schedule to determine the next time the job should start.

These jobs use a separate partition, account, and QoS, which should not be changed. The cron partition is made up of login nodes and only accepts cron jobs, so there should be little problems scheduling jobs at specific times. Cron jobs will persist until they are cancelled, have a problem resubmitting themselves, or job state for the entire cluster is lost. It would probably be wise to add mail notification to these scripts if necessary. It should be very rare for the job state of the cluster to be lost.