How to Troubleshoot Crontab Problems

Knowing how to troubleshoot your cron services will help determine why your script isn’t running as expected. There are several things you can check when you need to troubleshoot CRON:

View Cron Service Stats

$ sudo systemctl status cron.service
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-07-16 13:45:10 CDT; 2 days ago
     Docs: man:cron(8)
 Main PID: 1059 (cron)
    Tasks: 1 (limit: 4703)
   CGroup: /system.slice/cron.service
           └─1059 /usr/sbin/cron -f

Jul 19 12:40:01 site.com CRON[23951]: (root) CMD (/usr/local/sbin/ufw-update.sh >/dev/null 2>&1)
Jul 19 12:40:01 site.com CRON[23950]: pam_unix(cron:session): session closed for user root
Jul 19 12:45:01 site.com CRON[23987]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 19 12:45:01 site.com CRON[23988]: (root) CMD (/usr/local/sbin/ufw-update.sh >/dev/null 2>&1)
Jul 19 12:45:02 site.com CRON[23987]: pam_unix(cron:session): session closed for user root

Get PID of Cron

$ pgrep cron
1059

Script Must be Executable

$chmod +x script.sh

Viewing Syslog Messages About Crontab

$ grep CRON /var/log/syslog
Jul 19 12:40:01 site.com CRON[23951]: (root) CMD (/usr/local/sbin/ufw-update.sh >/dev/null 2>&1)
Jul 19 12:40:01 site.com CRON[23950]: pam_unix(cron:session): session closed for user root
Jul 19 12:45:01 site.com CRON[23987]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 19 12:45:01 site.com CRON[23988]: (root) CMD (/usr/local/sbin/ufw-update.sh >/dev/null 2>&1)
Jul 19 12:45:02 site.com CRON[23987]: pam_unix(cron:session): session closed for user root

Crontab INSECURE MODE

$ grep CRON /var/log/syslog
2015-02-05T08:47:29.283850+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

During backup and restore specifically, you might need to correct a permission. The requirement is only the user to have read and execute permissions to the /var/spool tab

$ sudo chmod 600 /var/spool/cron/crontabs/user

You will need to reload the crontabs after a permission change.

$ sudo touch /var/spool/cron/crontabs

Comments in Crontab

you can add a hash in front to comment/note

Echo the Path in Crontab Scripts

Most errors are caused by path being incorrectly used when calling the script. By default only /bin and /usr/bin are available. Add this to your script that you call from crontab and look at what path shows. Add a line that tells you the path your script sees in the top of your script

#!/bin/bash
/bin/echo $PATH > /root/path.txt

You can force the path manually by adding this to the crontab -e:

PATH=/usr:/usr/bin:/path/to/whatever

Or you can modify each script with a special variable:

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows

Which Path for Cron Scripts?

You can always use “which " to find the path you should use, and put the whole path in your script, if you are struggling with figuring out paths. You can see what the actual path should be using the “which” command:

$ which date
/bin/date

Echo the Entire Cron Environment in Script

Just like path problems will prevent the script, so will environment variables. Add this to your script that you call from crontab, then analyze your environment.

#!/bin/bash
/usr/bin/env > /root/allEvnVars.txt

Nested Crontab Variables

You can add variables to crontab -e and they will work. However, it will not work to use nested variables (a variable in another variable like bash scripting).

Last Line of Cron Job Doesn’t Run

Cron requires all commands to be terminated with a new line. Manually add a new line in your script or make sure the dos2unix has been run on your script and then view it again in vim to make sure line breaks and new lines are as expected.

$ dos2unix somescript.sh
$ cat somescript.sh

Crontab Errors in Formatting

Cron doesn’t like special characters, and one prime example is the % sign. You must escape the % if you use it. This will happen if you try to use auto generated dates without escaping them. The correct format is:

* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")"

Bash Shell vs sh

Try running the command in sh

$ sh script.sh

or force it to run in bash:

$ bash -c "script.sh"

Or force all cron jobs to use bash in top of crontab -e

SHELL=/bin/bash

Make sure your scripts also have proper shebang:

#!/bin/bash