Crontab (cron table) is a configuration file that specifies shell commands to run periodically on a given schedule. It is commonly used to automate system maintenance or administration. Crontab is available in almost Linux distribution and easy to use.
There are several reasons for that. Following is top 5 reason we might have
Although Crontab is available in almost Linux distribution by default today, there is customized version of Linux that misses cron package. To install cron…
On RHEL based systems (RedHat / CentOS / Fedora)
$ sudo yum install cronie
On Debian based systems (Debian / Ubuntu / Mint)
$ sudo apt-get install cron
If you Linux distribution doesn’t have package manager, you can install cronie from its source code.
The cron scripts are called and executed on a given schedule by a crontab daemon software. If your cron service isn’t running for some reason, your scripts will not be execute. To start cron service:
# On RHEL based systems, use
Also make sure the cron service will start on boot.
# On RHEL based systems , use
Cron service supports to run external scripts which put in
cron.weekly directories. According to RUN-PARTS(8), your script filenames must follow these rules:
If neither the –lsbsysinit option nor the –regex option is given then the names must consist entirely of ASCII upper- and lower-case letters, ASCII digits, ASCII underscores, and ASCII minus-hyphens.
If the –lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^?([a-z0-9.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-zA-Z0-9_-]+$).
If the –regex option is given, the names must match the custom extended regular expression specified as that option’s argument.
A common naming issue i usually see is using the dot character in the filename as we want to specify the file extension when saving a script. This dot character breaks the rule and make cron service ignore your script. If you have any scripts like
backup.sh, you should rename it to
The script must be executable so your cron service can run it. To give executable permission to your script, you can use
chmod command. For example:
$ sudo chmod +x /etc/cron.hourly/backup
Note: Many cron service also reject the script that has insecure mode. You might have following error message in the syslog.
$ grep -i cron /var/log/syslog
2018-01-06T03:47:49.283841+01:00 ubuntu cron: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
To fix it, we have to set the proper file permission for the script.
$ sudo chmod 600 /etc/cron.hourly/backup
There are several reasons for this. Let’s see some common cases below
In most of the cases, we should use shebang at the start of the script. For example, if your script is written in Bash, try to use
#!/bin/bash, in Python use
#!/usr/bin/env python, etc. This allow scripts and data files to be used as commands, hiding the details of their implementation from users and other programs, by removing the need to prefix scripts with their interpreter on the command line.
Another common issue is related to the environment variable. You tested your script by excuting it from the command line and it worked as expected but somehow it didn’t work in crontab. To troubleshoot, you can log the actual environment variables that loaded in the cron by having this simple command in cron table.
* * * * * env > /tmp/check.txt
If you are using
crontab -e to write cron commands, you might want to load the environment variables that needed by your scripts / applications. These variables can be loaded directly by putting right before the command, for example:
0 10 * * * MY_ENV_VAR=my_value my_command my_parameters
Or load them from a file
0 10 * * * . $HOME/.my_vars; my_command my_parameters
Or if those variables are loaded under your user profile, let’s say bash profile for example. You can specify the shell at the begining of crontab.