10

I have a strange problem of being to able to run a bash script from commandline but not from the crontab entry for root. I am running Ubuntu 12.04.

* * * * 1-5 root /home/xxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/jmeter-cron-randomise.sh >> /home/xxxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/cron.log

If I run the script from the cmd line using bash, it works fine but sh fails with following error:

> jmeter-cron-randomise.sh: 7: jmeter-cron-randomise.sh: arithmetic
> expression: expecting primary: "  % 1 "

Having googled the problem, it seems like standard shell doesn't have the same math operators, like % (modulus), as bash. I'm Not sure why the cron job is failing in the script? I am assuming it is because it's not using the bash shell? It's definitely being fired by the cron daemon (can see it in /var/log/syslog). Any help much appreciated.

Improve this question
5
  • What's on your shebang line? Commented Oct 23, 2014 at 15:02
  • Does your cron run the command with /bin/sh? It looks like it probably does because the error is what you'd like get if you ran the script with sh instead of bash (as in: sh /home/…/jmeter-cron-randomise.sh). And on Ubuntu, /bin/sh is often dash, not bash. To fix, use bash /home/…/jmeter-cron-dandomise.sh >> … in your crontab entry. Commented Oct 23, 2014 at 15:13
  • Looks like it is running sh. How can I force it to run bash apart from the shebang line? Commented Oct 23, 2014 at 15:16
  • kal: run bash /path/of/script.sh. This bash should be the output of which bash, that is, the full path of the binary. Commented Oct 23, 2014 at 15:17
  • @kal What's the complete output of head -n 1 /home/xxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/jmeter-cron-randomise.sh | cat -vE? This will show the first line in a visually unambiguous way, to help determine whether e.g. a byte order mark is invalidating your shebang. Commented Oct 23, 2014 at 16:58

3 Answers 3

Reset to default
22

You likely need to tell cron that the shell to use is the bash shell as it defaults to sh. You can do that for all crontab entries by putting this line in your crontab:

SHELL=/bin/bash

Note that this will cause all scripts in the crontab to be run under bash which may not be what you want. If you want to change the crontab line itself to just run bash, change it to this:

* * * * 1-5 root /bin/bash /home/xxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/jmeter-cron-randomise.sh >> /home/xxxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/cron.log 2>&1

Note that I have also caused stderr to be written to the cron.log file (2>&1) which may not be what you want but is pretty common practice. This may help you further diagnose errors from the script.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

This is almost right: it can be /bin/bash or it can be /usr/bin/bash or whatever. It is interesting to mention that the real full path can be obtained with which bash.
thanks. reverting to using the crontab entry via crontab -e for root user and facing the original problem i can see helpful failure messages now ------ Running the jmeter-cron-randomiser script min = 1 random = 1933 rmin = 0 /bin/sh: 1: root: not found /bin/sh: 1: root: not found /bin/sh: 1: root: not found
thanks @viritude. Overall problem resolved via edit of /etc/crontab.
@fedorqui - While that is correct, the path was already known. kal mentioned it was /bin/bash in his first comment on the question.
1

In case this helps anyone: for me this appeared to be because I had ended up with "DOS" line endings (CR-LF) instead of "unix" line endings (LF). This can be checked using od or your favourite hex dump tool, e.g.: 

od -c <script_file>

... and look for \r\n instead of just \n.

It seems (and this article supports it) that the CR character stops the "shebang" from working because it's interpreted as part of the shell executable's filename.

(The line endings themselves appeared because the file came from a git repository and was transferred via a Windows machine).

Improve this answer

Comments

-1

I also encountered this problem trying to schedule a database backup as root and it made me pull my hair out! I was working on a CentOS 7 box. Whenever I would check /var/spool/mail/root I would see a log: sh: root: command not found, yet the command would run perfectly in the terminal.

This is what worked for me:

  1. I created the crontab entry using crontab -e while logged in as root.

  2. Using the command above as an example:

    * * * * 1-5 root /home/xxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/jmeter-cron-randomise.sh >> /home/xxxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/cron.log

I deleted the root user entry like: * * * * 1-5 /home/xxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/jmeter-cron-randomise.sh >> /home/xxxxxxx/jmeter/VerificationService-0.0.1-SNAPSHOT/cron.log

That solved my problem.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.