Understanding the crontab

The Linux crontab is relatively easy to understand. Still, it can generate a lot of frustration when debugging or even when creating an entry. In the present article I have gathered resources and information that I’ve used over the time when playing with cronjobs.

The standard syntax for a cronjob is the one below:

* * * * * user command

1st * – the minute when the command should run ; takes values from 0 to 59

2nd * – the hour when the command should run ; takes values from 0 to 23

3rd * – the day of the month when the command should run ; takes values from the days of the month, from 1 to 31

4th * – the month when the command should run ; takes values from 1 (January) to 12 (December)

5th * – the day of the week when the command should run ; takes values from 0 to 7, where Sunday can be either 0 or 7, the other days fitting between

user – the user that will run the command or script specified next ; not necessary when doing per user cronjobs (as it can be seen further in the post on “Editing the crontab directly” )

command – the command line command that you want to run ( e.g. ping domain.com ) or the path to a script ( e.g. /home/user/myscript.sh)

The “*” value is default, meaning that the specified command will apply for each value of the elements.

* * * * * root script.sh

Will run script.sh as root every minute of every hour of every day of month of every month but

0 * * * * root script.sh

Will run script.sh as root every 0th minute of every hour (right at the beginning of the hour) of every day of month of every month.

By running the crontab -e command, you will be able to edit the crontab for you user directly. Your chosen default text editor will open a file with a lot of comments, like below. After the line, you are to add your cronjobs, one per line.

Creating a separate file for cronjobs and storing it appropriate

You will find several folders in /etc and their name starts with “cron.”. These are cron.daily, cron.hourly, cron.monthly, cron.weekly and cron.d. The first 4 folders are associated with a period in which cronjobs should run. Scripts placed in each of these folder will be ran according to the period in the name. As suggested by the Ubuntu community, we should avoid editing the crontab directly, and place a file under the appropriate directory. If we can’t decide on the directory and want something centralized, creating a file in the folder cron.d would solve that. Files should have 755 permissions. You can check out the permissions prettified post for how to do that.

Examples

hourly cron

0 * * * * script.sh

daily cron

0 20 * * * script.sh

weekly cron

0 20 * * 2 script.sh

Debugging your cronjobs

Reasons for your cronjobs not working are numerous, but in most cases, simple check ups that apply in any other situation will fix it. There are some small things that one might not ever think about though – check them below.

Check the cron service

sudo service cron status

Check your syntax or file

It should end with a newline – at the end of your last line in the file, hit enter so that you have a newline ending the file

Permissions – files placed in either of the cron.* folders should have 755 permissions

No dots in file names – files placed in either of the cron.* folders should not contain any dots : “.”

Verify the path of the script that you are using

Do a sanity check on the syntax using online resources like cronchecker

Check the log files

cat /var/log/syslog | grep crontab

Resources worth checking

Sometimes you are in need of services that handle the cronjob for you. This may be due to multiple reasons, such as not having access to the server to activate cronjobs or needing external activation of a script at a certain time. What I have used is EasyCron , offering a free plan that suits most developer needs but for more production related tasks you can upgrade to payed packages.