Top 5 reasons your crontab scripts are not working

The Crontab

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.

Why crontab scripts are not working?

There are several reasons for that. Following is top 5 reason we might have

1. Crontab software is not installed

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.

2. Your cron service is not running

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
$ sudo service crond start

# Or using systemd
$ sudo systemctl start crond

# Debian based systems, use
$ sudo service cron start

# Or using systemd
$ sudo systemctl start cron

Also make sure the cron service will start on boot.

# On RHEL based systems , use
$ sudo chkconfig crond on
# Or using systemd
$ sudo systemctl enable crond

# On Debian based systems, use
$ sudo update-rc.d cron defaults
# Or using systemd
$ sudo systemctl enable cron

3. Your cron script has a bad file name

Cron service supports to run external scripts which put in cron.d, cron.daily, cron.hourly, cron.monthly and 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 backup.

4. Your cron script has bad permission

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[43561]: (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

5. Your cron script cannot be executed properly

There are several reasons for this. Let’s see some common cases below

Shebang

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.

Missing environment variables

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.

SHELL=/bin/bash

0 10 * * * my_command my_parameters