The Linux crontab, scheduling events

Last updated
Save as PDF

Page ID: 37617

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

Scheduling data collection events is critical for highly automated IoT systems.

Programs can be scheduled to run at boot time or anytime throughout the day.

The @ schedules:

# string             meaning
# ------           -----------
# @reboot       Run once, at startup.
# @yearly       Run once a year, "0 0 1 1 *".
# @annually     (same as @yearly)
# @monthly      Run once a month, "0 0 1 * *".
# @weekly       Run once a week, "0 0 * * 0".
# @daily        Run once a day, "0 0 * * *".
# @midnight     (same as @daily)
# @hourly       Run once an hour, "0 * * * *".

The above @ schedules demonstrate the shorthand for some event timing.

For example @hourly is equivalent to "0 * * * *"

Examples of cronjobs:

I want to know if the power goes out where I live. If the power fails then the RPi does not send a marker to the cloud server at the scheduled time. My Android phone is programmed to check the existence of the marker on the server. If the marker exists it deletes the marker. If the marker does not exist I get a text to speech message on the phone indicating that a failure occurred.
For some networks the RPi gets a different IP when it boots up. To avoid having to connect a monitor and keyboard to get the new IP a boot cron is used to email the new IP to the user.

# Check to see if a crontab already exists.
 crontab -l
 
# If a crontab already exists then make a backup so that any previous work is not lost.
crontab -l > crontab.org

If a crontab does not exist for the user the following message is displayed.

The above output is from an old Red Hat server, output for a different OS may not be the same.

There are two ways to approach editing of a crontab.

Edit the crontab directly
Edit a file containing the cron-table then initialize the crontab using the file.

The following is an example of editing the crontab directly.

Note; for the first time edit the choice of editors is required.

In the above example saving the edits makes the changes active.

However there is no backup of your cron-table.

The following method makes a backup.

crontab -l > crontab.bak

Alternatively start with a cron-table file, edit that file, and make the data in new table file active.

A well-documented cron-table file named crontabRPi.scr can be downloaded to your RPi using the following command.

git clone https://github.com/phwilliams256/Example-crontab-for-Raspberry-Pi.git

After cloning the directory you can change to the directory and see the containing the crontab source.

cd Example-crontab-for-Raspberry-Pi

in the directory Example-crontab-for-Raspberry-Pi you will find the crontab source file named crontabRPi.scr.

Note, there are no active lines in this file (they are commented out). Activate any lines of interest by removing the comment ‘#’, saving the file, and activating the changes with the following command

The following command puts the content of cron-table file (crontabRPi.scr) in the active crontab.

crontab crontabRPi.scr

# Confirm the changes.
crontab -l

This second method insures that there always exists a document of the current crontab (crontabRPi.scr). This document will be saved with any backup of the user account data.

Issues to be aware of;

In most cases the full path to the application is required.

The full path to the input and output files is always required. This is because the crontab has no knowledge of the user’s path only the system path.

pi@serverNine$ cat touchFilesExmaple.sh
#!/bin/bash

# For scripts run on the command line the relative path to the data is best
# The directory containing the script can be copied and the script run.
touch ./touch.tmp

# For scripts run through the crontab the full path must be
#  given to all input and output files.
mkdir -p /home/pi/temperatureSensor
touch /home/pi/temperatureSensor/touch.tmp

In the example script above the “touch” command is known to be in the system path. If it was not in the path or we did not know it was in the path then give the full path to the program “touch”.

pi@serverNine$ which touch
/usr/bin/touch

mkdir -p /home/pi/temperatureSensor
/usr/bin/touch /home/pi/temperatureSensor/touch.tmp

Useful patterns:

# minute (0-59),
#    |
#    |
#   Mins 
    0,30
# Run the command at the top and bottom of the hour

# hour (0-23),
#   |
#   |
# Hours
 0-6,21-23
# Only when I am sleeping

#     hour (0-23),
#        |
#        |
#      Hours
 1,3,5,7,9,11,13,15,17,19,21,23
# Every other hour, odd hours

#     hour (0-23),
#        |
#        |
#      Hours
  0,2,4,6,8,10,12,14,16,18,20,22
# Every other hour, even hours

#     hour (0-23),
#        |
#        |
#      Hours
        */2
#  Every two hours

# minute (0-59),
#  |
#  |
# Mins
  */10
# Every 10 minutes

# day of the week (0-7 with 0=7=Sunday).
#   |
#   |
# Day of
# the week
  1-6
# Monday through Saturday, not Sunday

Cron examples can be found here;

https://crontab.guru/examples.html