Cronjob 发送电子邮件“命令失败，退出状态 1”当一切都没有失败时
我最近一直在尝试 cronjobs，并将其设置如下：
crontab：
SHELL=/bin/sh
[email protected]
26 11 * * * wget http://diruser:[email protected]/path/to/file.php
在它运行的 php 文件中是一个 SQL 查询，目前仅运行插入。这工作正常并运行插入，但是当我查看它生成的电子邮件时，它说：
电子邮件：
wget http://diruser:[电子邮件受保护]/path/to/file.php：
命令失败，退出状态为 1
我只是想知道是否有人知道为什么它会返回命令失败？它显然没有失败，但电子邮件回复让我觉得我在某个地方做错了。
另外，将 cron 正在调用的文件放入受密码保护的目录中是否是一种好的做法，或者是否有更好的方法来解决它（例如检查请求 ip 是否是服务器的 IP 或其他内容）。
I've been experimenting with cronjobs recently and have it setup like so:
crontab:
SHELL=/bin/sh
[email protected]
26 11 * * * wget http://diruser:[email protected]/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://diruser:[email protected]/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).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最有可能的是，
wget会抛出错误，因为它无法保存结果。默认情况下，wget将尝试将结果存储在磁盘上。在 cron 作业中运行时，工作目录（通常）为/。作为用户，您可能无法在那里存储文件。相反，告诉
wget删除结果，或通过管道将其传输到/dev/null。狐狸的例子：Most likely,
wgetthrows an error because it cannot save the result. By defaultwgetwill 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
wgetto drop the result, or pipe it to/dev/null. Fox example:我不知道为什么会产生错误。但在我看来，通过 wget 调用 PHP 并不是一个好的做法。您可以编写 PHP 脚本，该脚本无法通过 Apache（或 Nginx 或其他 HTTP 服务器）访问，并且可以从 cron 调用：
更好的方法是像单独的用户一样调用它，例如
phpuser，谁将仅拥有脚本所需的权限。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:
And better way is to call it like an separated user,
phpuserfor example, who will have only permissions that script needs.尝试：
或者
1. crontab 需要命令的完整路径，才能运行它
2.
wget将尝试保存file.php的响应，如果它没有必要的权限，它将失败。这就是为什么您应该将输出重定向到文件以外的其他位置，这是通过> 完成的/dev/null。程序的输入输出有3个标准源，即
STDIN、STDOUT、STDERR，编号分别为0代码>、<代码>1、<代码>2。当您使用大于
>重定向输出时，如果您没有明确提及要重定向哪一个，则默认为STDOUT(1) 。因此，我们将所有STDOUT输出重定向到 null/trash，并将所有错误2>&1重定向到STDOUT，后者将依次消失如之前的规则所示，放入垃圾箱。Try:
Or
1. crontab needs the full path to the command, in order to run it
2.
wgetwill try to save the response of thefile.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 as0,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 isSTDOUT(1). Thus, we will redirect allSTDOUToutput to null/trash, and all errors2>&1toSTDOUT, which in turn will go to trash, as denoted by the previous rule.