Almost all problems with scripts properly running from the commandline, but not from
cron come from the setting of the PATH variable. According to
man 5 crontab for Vixie cron:
On the Debian GNU/Linux system, cron supports the pam_env module, and
loads the environment specified by /etc/environment and /etc/secu‐
rity/pam_env.conf. It also reads locale information from
/etc/default/locale. However, the PAM settings do NOT override the
settings described above nor any settings in the crontab file itself.
Note in particular that if you want a PATH other than "/usr/bin:/bin",
you will need to set it in the crontab file.
Although the details might be different on other systems and/or other
cron implementations the PATH the script gets handed from cron is likely to be more restricted than the one in your shell.
This means that anything your scripts (or the scripts/programs invoked from it) call that is in e.g.
/usr/local/bin does not get found when running invoked from
You can test this by calling your script the following way:
You can solve this by extending your path in the crontab file:
PATH = /usr/local/bin:/usr/bin:/bin
before the actual line of calling your script. Variables will not be substituted (so don't do
PATH = /usr/local/bin:$PATH).
It also good practise to include an echo statement to some log file near the top of your script:
echo "invoking script" > "$TSTLOG"
date >> "$TSTLOG"
echo "$PATH" >> "$TSTLOG"
(overwriting by the
echo on purpose here). So you can check that your program was called, and what kind of environment caused this.
You should also check your mail. On the system itself, if the system is not set up for forwarding email to your normal account. Many cron emails get unnoticed because there is no
MAILTOemail@example.com and the system just puts the messages where for the local account used for cron can read them.