Why can't cron job find basic Linux commands?

Question

I'm trying to set up a cron job to run a PHP script daily as part of a web-based booking system. It's been running perfectly for several years on a different Apache server using this in the crontab:

0 3 * * * wget -q -O /dev/null http://www.my_other_domain.org.uk/scheduled/my_script.php

I've just installed the script on another Apache server, and it runs correctly when called through the browser. However when I try to use cron, the cron daemon gives the message:

-: warning: setlocale: LC_ALL: cannot change locale (en_GB.utf-8)
-: wget: command not found

When I tried

0 3 * * * /usr/bin/env wget -q -O /dev/null http://www.mydomain.org.uk/scheduled/my_script.php

I got the message:

-: warning: setlocale: LC_ALL: cannot change locale (en_GB.utf-8)
-: /usr/bin/env: No such file or directory

Firstly, am I right in assuming that the setlocale warning is not relevant to the problem?

I've also tried

0 3 * * * /usr/bin/php /var/www/vhosts/mydomain/httpdocs/scheduled/my_script.php

which gives

-: /usr/bin/php: No such file or directory

I also tried putting a shebang as the first line of my script, and getting cron to call it using the full path. The cron daemon reported that there was no such file or directory as /[full_path]/my_script.php .

Trying to use curl was no better.

I haven't got shell access to the server and I've been setting up the cron job through the Plesk control panel. The cron job seems to be running as scheduled. The system administrator did the following for me:

#which php
/usr/bin/php

#which wget
/usr/bin/wget

#which curl
/usr/bin/curl

That seems to confirm that the commands are in the right location.

The above is an abbreviated history - I've lost count of the permutations and combinations I've tried, mostly as a result of reading advice in this and other forums.

Can anyone tell me why the cron job is unable to find the commands and suggest a solution?

Answer 1

Your shell knows where to find executables by looking in your PATH, which is set by your environment. cron does not share the same environment. Adding this at the top of the crontab should tell it where to find commands as you expect:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Answer 2

Going by the symptoms you report, this goes beyond a broken PATH: that wouldn't affect /usr/bin/env. However, it's difficult to be sure because your reporting is inconsistent. Did you write /usr/bin/env or usr/bin/env?

Make sure that there are only ASCII characters in your crontab, no unbreakable spaces or non-printing characters. Also, check that you haven't defined some environment variables that may be causing trouble, such as PATH or LD_LIBRARY_PATH.

If /usr/bin/env: No such file or directory strongly suggests that there is a misconfiguration on the server that you cannot fix. The virtual environment or security framework on the server isn't allowing you to run commands, at least from cron. It's impossible to know what could be wrong without knowing what kind of environment the server is running. This is something that the system administrator must fix.

The setlocale error is not the cause of the problem but may well be another symptom.

Answer 3

Thanks to all who answered for your suggestions. It's been fairly slow trying them out, as I have had to pass them to the system adminstrator who then speaks to his technical support. Tech support were able to demonstrate that cron jobs worked when entered in the root crontab, so I asked the system administrator to put my jobs in there - they still didn't work, despite using identical syntax to the one that tech support ran.

At that point, my client decided that they didn't really need email reminders after all, so I've stopped trying. Thanks again for your advice.