我最近一直在尝试使用cronjobs并设置如下：
的crontab：
SHELL=/bin/sh
MAILTO=me@me.com
26 11 * * * wget http://diruser:pass@domain.com/path/to/file.php
在php文件中，它运行的是一个SQL查询，目前只运行一个插入。这工作正常，并运行插入，但当我看到它生成的电子邮件时，它说：
电子邮件：
wget http://diruser:pass@domain.com/path/to/file.php：
命令失败，退出状态为1
我只是想知道是否有人知道为什么它会返回命令失败？它显然不会失败，但电子邮件回复让我觉得我在某处做错了。
另外，将cron调用的文件放在受密码保护的目录中是一种好习惯，还是有更好的方法（例如检查请求ip是服务器的内容还是其他内容）。
答案 0 :(得分：1)
最有可能的是，wget会抛出错误，因为它无法保存结果。默认情况下，wget将尝试将thr结果存储在磁盘上。在cron作业中运行时，工作目录（通常）为/。作为用户，您可能无法在那里存储文件。
相反，请告诉wget删除结果，或将其传递给/dev/null。福克斯的例子：
wget -O - -q http://diruser:pass@domain.com/path/to/file.php
答案 1 :(得分：0)
我不知道为什么会产生错误。但在我看来，通过wget调用PHP并不是一件好事。您可以编写无法通过Apache（或Nginx或其他HTTP服务器）访问的PHP脚本，并且可以从cron调用：
SHELL=/bin/sh
MAILTO=me@me.com
26 11 * * * php /path/to/file.php
更好的方法是将其称为分离用户，例如phpuser，只拥有脚本所需的权限。
答案 2 :(得分：0)
尝试：
26 11 * * * /usr/local/bin/wget "http://diruser:pass@domain.com/path/to/file.php" > /dev/null 2>&1
或者
26 11 * * * /usr/bin/wget "http://diruser:pass@domain.com/path/to/file.php" > /dev/null 2>&1
1。 crontab需要命令的完整路径才能运行它
2。 wget将尝试保存file.php的响应，如果它没有必要的权限，它将失败。这就是为什么你应该将输出重定向到其他地方，而不是文件，这是由> /dev/null完成的。
程序的输入和输出有三个标准来源，即STDIN，STDOUT，STDERR，分别编号为0，1， 2。
使用大于>重定向输出时，如果没有明确提及要重定向的输出，则默认值为STDOUT（1）。因此，我们会将所有STDOUT输出重定向到null / trash，并将所有错误2>&1重定向到STDOUT，而这些错误又会转到垃圾箱，如前一条规则所示。