I have a shell script test.sh in /home/username

The test.sh file contains the following lines -


cd /home/username/bin

sh launch.sh  ParameterName

#launch.sh is in /home/username/bin directory

I have set up a crontab entry as follows -

* * * * * /home/username/test.sh

When I run /home/username/test.sh on terminal it is working properly. But it is not working from cron.

  • Which Linux distribution are you using? do you have more processes running at crontab? are they running? have you try to add your path into the shell script?
    – dgsleeps
    Feb 24 '15 at 6:26
  • Have you checked that everything your script needs is in the PATH cron provides? (e.g. by executing PATH=/usr/bin:/bin /home/username/test.sh).
    – Anthon
    Feb 24 '15 at 6:33
  • If you run it without sh on the command line, and it fails when you run it with sh from the Cron job, that could be the problem. Try without the sh. Is this actually a Bash script?
    – tripleee
    Feb 24 '15 at 8:12

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 cron.

You can test this by calling your script the following way:

 PATH=/usr/bin:/bin /home/username/test.sh

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 MAILTO=your_email@your.provider and the system just puts the messages where for the local account used for cron can read them.


Two options:

Option 1 - Have you chmod +x test.sh?

That way you can execute with ./test.sh rather than sh test.sh.

Option 2 - If you don't want to chmod the file, change your crontab entry to

* * * * * /usr/bin/sh /home/username/test.sh

Additionally, if you choose the latter, you should verify the sh binary location with

which sh

  • None of these are necessary as the script runs from the commandline.
    – Anthon
    Feb 24 '15 at 6:34
  • 1
    @Anthon The question is how they are being called. Sure they may be run manually from the commandline, but if they are being called differently from cron, that could be the problem. If you expect cron to run ./tests.sh and only test it with sh test.sh you will have problems.
    – sam
    Feb 24 '15 at 6:46
  • But the OP clearly states /home/username/test.sh is run from the commandline. Not that sh is run with some parameters. It is also way more likely that the OP has not restricted the PATH in his/her shell, the way that cron does.
    – Anthon
    Feb 24 '15 at 7:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.