Cronjob emailing "command failed with exit status 1" when nothing fails

I've been experimenting with cronjobs recently and have it setup like so:

crontab:

SHELL=/bin/sh
MAILTO=me@me.com
26 11 * * * wget http://diruser:pass@domain.com/path/to/file.php

Within the php file it runs is a SQL query which at the moment just runs an insert. This works fine and runs the insert but when I look at the email it produces it says this:

email:

wget http://d开发者_StackOverflow社区iruser:pass@domain.com/path/to/file.php:

Command failed with exit status 1

I was just wondering if anyone knows why it would return command failed? It obviously doesn't fail but the email response makes me think I've done something wrong somewhere.

Also, is it good practice to put the file the cron is calling inside a password protected directory or is there a better way around it (such as checking that the request ip is that of the server or something).

Most likely, wget throws an error because it cannot save the result. By default wget will try to store thr result on disk. When running in a cron job, the working directory is (usually) /. You , as a user, probably cannot store a file there.

Instead, tell wget to drop the result, or pipe it to /dev/null. Fox example:

wget -O - -q http://diruser:pass@domain.com/path/to/file.php

I have no idea why error is produced. But in my opinion this is not good practive to call PHP via wget. You can write PHP script which will not be accessible over Apache (or Nginx or other HTTP server) and can be called from cron:

SHELL=/bin/sh
MAILTO=me@me.com
26 11 * * * php /path/to/file.php

And better way is to call it like an separated user, phpuser for example, who will have only permissions that script needs.

Try:

26 11 * * * /usr/local/bin/wget "http://diruser:pass@domain.com/path/to/file.php" > /dev/null 2>&1

Or

26 11 * * * /usr/bin/wget "http://diruser:pass@domain.com/path/to/file.php" > /dev/null 2>&1

1. crontab needs the full path to the command, in order to run it

2. wget will try to save the response of the file.php, if it doesn't have the necessary permissions, it will fail. That's why you should redirect the output somewhere else, other than a file, which is accomplished by > /dev/null.

There are three standard sources of input and output for a program, i.e. STDIN, STDOUT, STDERR, respectively numbered as 0, 1, 2.

When you redirect the output by using the greater-than >, if you don't explicitly mention which one you want to redirect, the default one is STDOUT (1). Thus, we will redirect all STDOUT output to null/trash, and all errors 2>&1 to STDOUT, which in turn will go to trash, as denoted by the previous rule.