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
- Fix “sudo command not found”
- Install a Specific Version with apt-get on Ubuntu/Debian
- Fix Ubuntu/Debian apt-get “KEYEXPIRED: The following signatures were invalid”
- How to Test a Cron Job
- How to Unzip Into a Folder
- How to Show Your Elasticsearch Version on Ubuntu/Debian
- Use “which” in Linux to find the Location of an Exetable
- Sort “ls” by Last Changed Date
- How to Shutdown a Machine
Testing a Cron Job
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
At first, we checked whether the
cron service is actually running. On Ubuntu and Debian system, you can check the status using the
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.