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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$ 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
|
1 2 3 4 |
$ pgrep cron 1059 |
Script Must be Executable
|
1 2 3 |
$chmod +x script.sh |
Viewing Syslog Messages About Crontab
|
1 2 3 4 5 6 7 8 |
$ 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
|
1 2 3 4 |
$ 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
|
1 2 3 |
$ sudo chmod 600 /var/spool/cron/crontabs/user |
You will need to reload the crontabs after a permission change.
|
1 2 3 |
$ 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
|
1 2 3 4 |
#!/bin/bash /bin/echo $PATH > /root/path.txt |
You can force the path manually by adding this to the crontab -e:
|
1 2 3 |
PATH=/usr:/usr/bin:/path/to/whatever |
Or you can modify each script with a special variable:
|
1 2 3 4 5 |
#!/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
You can see what the actual path should be using the “which” command:
|
1 2 3 4 |
$ 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.
|
1 2 3 4 |
#!/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.
|
1 2 3 4 |
$ 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:
|
1 2 3 |
* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")" |
Bash Shell vs sh
Try running the command in sh
|
1 2 3 |
$ sh script.sh |
or force it to run in bash:
|
1 2 3 |
$ bash -c "script.sh" |
Or force all cron jobs to use bash in top of crontab -e
|
1 2 3 |
SHELL=/bin/bash |
Make sure your scripts also have proper shebang:
|
1 2 3 |
#!/bin/bash |