从 cron 脚本编写 crontab 返回 127 错误答案

【问题标题】：writing crontab from cron script returns 127 error从 cron 脚本编写 crontab 返回 127 错误
【发布时间】：2013-08-25 01:30:36
【问题描述】：

我正在处理一些必须从 crontab 执行的脚本。其中一些重写了 crontab。

in.php 定义 read.php 是否应该由 crontab 运行。然后 read.php 由 crontab 执行。这很好用。

read.php 执行时，它可能会检测到它不应该运行，如果发生这种情况，它会重写 crontab 以避免自己执行，直到 in.php 再次重写 crontab。问题是这第二步不起作用。

我一直在寻找错误，我发现我的 cron.txt 编写正确。但是，crontab 命令失败并返回 127 错误。但是当我手动执行 read.php 时一切正常。

两个脚本使用相同的函数来重写 crontab。但这只是发生在 read.php 中，而不是 in.php 中。

crontab 执行任务后有时间重写吗？它可以解释我的问题，因为 in.php 比 read.php 需要更长的时间来执行。

谢谢！

PD：我已经检查了 crontab 命令中的 cron.txt 的路径是否是自动执行的，如果我是手动执行的。

编辑：当我谈到重写 crontab 时，我指的是重写 cron.txt 文件并执行 crontab [path]/cron.txt

【问题讨论】：

标签： php crontab

【解决方案1】：

如果无法访问您的代码，我们只能推测出了什么问题，但更简单、更健壮的解决方案是添加一个包装器来决定是否执行真正的作业，并始终从crontab。在最简单的情况下，仅当文件存在时才执行：

55 * * * * test -x hourly && ./hourly

将$HOME/hourly 重命名为其他名称以防止其执行。

或者，如果条件简单，只要不满足条件就让脚本提前退出。

case $moon_phase in full | new ) exit 0 ;; esac

【讨论】：

事实上，如果 read.php 检测到它不应该运行，它不会做任何事情。（在这种情况下，它会重写 crontab）。问题是检查它是否必须运行涉及一个 sql 查询，并且它每分钟都在执行。我正在考虑其他方法来做到这一点。事实上，其中之一是通过读取文件来检查 read.php 是否应该运行，并避免 sql 查询。在这种情况下，我不需要重写 cron。是的，我认为这会奏效。谢谢