Cron jobs are a nice way to automatically run scheduled tasks. The cron service in Linux systems is the typical approach when scheduling commands on the operating system.

Ubuntu/Debian Series Overview

Testing a Cron Job

Recently the certbot from Let’s Encrypt didn’t automatically renew SSL certificates anymore. We used a cron job and scheduled a command to run every 40 days to check whether certificates are up for renewal.

At some point, the cron job stopped and didn’t run CertBot. Here are two steps we used to approach this problem.

1. Check the cron Service

At first, we checked whether the cron service is actually running. On Ubuntu and Debian system, you can check the status using the systemctl or service commands:

sudo systemctl status cron

# or
sudo service cron status  

In our case, this was the issue. The cron service was inactive. It seemed like it didn’t start on system boot.

In case your cron service runs properly, you should go ahead and check the second step.

2. Create a Sample Cron Job

The next step on your journey testing a cron job is to create a sample job. This sample job should create a new file in a directory.

What you expect is that the cron scheduler runs the job and with that creates the file.

Go ahead and open the user’s crontab in edit mode. You can do that with the crontab -e command:

# open the user’s crontab to edit the content
crontab -e  

Then add the following line in the crontab:

# the following job runs every 60s
* * * * *  /usr/bin/env > /home/<user>/created-by-cron

Here’s the full crontab content after adding the new job:

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
* * * * *  /usr/bin/env > /home/marcus/created-by-cron

Now you need to wait for one minute so that the cron scheduler processes the new line. A cron job has a granularity of 60 seconds, that’s the reason you need to wait.

In our example, the cron created the file:

marcus@FutureStudioServer:~$ ls  
created-by-cron  

Sweet! Now that you verified that you cron service works properly, you should remove the testing job from the user’s crontab.