Question

嗯，这不是真的，我确定这是一个原因，但我无法找到它！

我有一个脚本可能需要大约10分钟才能执行。它与我们使用的服务上的api进行了很多通信。它每隔24小时就会提取一些指纹。因此，除了这一点之外，它所做的事情是相当的。我发现的问题是脚本停止执行有点随意!!

即使使用

，我也无法找到导致我的脚本停止执行的任何错误

//for debugging
error_reporting(E_ALL);
ini_set('display_errors', '1');

打开调试，它全部干净。我也用过

set_time_limit(0);

所以它不应该超时。

话虽如此，我不知道如何获得更多的调试信息来弄清楚它停止了什么。我可以说脚本不应该达到任何内存限制或任何内容。我的意思是应该抛出一个错误，我已经完成并清理了这个脚本，就像我看到清理它一样。

所以我的问题是：当cron不应该结束时，什么是常见的原因？如何更有效地调试它？

Answer 1

您可以尝试使用register_shutdown_function()来定义在脚本关闭时执行的代码块。然后在cron中的主代码执行点上创建一个变量，其中包含正在进行的操作的详细信息。在关闭功能中，将其写入日志并检查日志以查看程序停止时的状态。当然，这是基于您的代码并非完全错误的假设。

您还可以使用

将标准echo语句和日志重定向到日志文件中

/path/to/cron.php > /path/to/log.txt 2>&1

2>&1表示标准错误(2>)被重定向到标准输出(&1)指向的同一文件描述符。因此，标准输出和错误都将重定向到{{ 1}}

更新：

下面是我通常在我的crons中使用的函数/流程：

/path/to/log.txt

然后我像这样使用它：

function addLog($msg)
{
    if(empty($msg)) return;
    $handle   = fopen('log.txt', 'a');
    $msg = $msg."\r\n";
    fwrite($handle,$msg);
    fclose($handle);
}

拥有所有这些日志比较繁琐，但是当cron搞砸了，它确实有帮助！

例如。当你看到你的log.txt，如果你看到类似的东西：

addLog("Initializing...");
init();
addLog("Finished initializing...");
addLog("Calling blah-blah API...");
$result = callBlahBlah();
addLog("blah-blah API returned value". $result);

并且没有条目显示Initializing... Finished initializing... Calling blah-blah API...，那么你知道函数调用blah-blah搞砸了。

Answer 2

当cron不应该结束时，常见的原因是什么？

根据我的经验，最常见的是cron用户具有不同的权限或不同的环境变量，而不是您从命令行执行它的方式。

让你的cronned程序将其环境转储到一个临时文件中，看看它是否符合你的期望。

crons无缘无故地停下来

2 个答案: