运行CRON时，“require”无声地失败

Question

我有一个从浏览器运行的备份脚本，没有问题。它从数据库中提取数据并将其写入2MB以下的ZIP文件。

它主要是从服务器运行的，但是当它碰到特定的行时，它会失败(悄悄的)：

require ('/absolute-path/filename');  // pseudo filespec

这是几个这样的陈述之一。这些库文件只做“内存中的东西”。我绝对排除了这条路是问题所在的任何可能性。我正在用条件is_readable()测试这个文件，输出它，并给自己发电子邮件。

$fs = '/absolute-path/filename'; // pseudo filespec
if (is_readable ($fs) ) { 
    mail('myaddress','cron','before require'); // this works reliably
    require ($fs); // can be an empty file ie. <?php ?>
    mail('myaddress','cron','after require'); // this never works.
}

当我注释掉require($fs)时，脚本仍在继续(主要见下面)。

我检查了行尾(看不见的字符)。并不是每个include-ed文件都有新行(NL)结束(Linux样式)，而不是换行符+回车(NL )(Linux样式)。

我已经尝试过要求一个空文件(只需要<?php ?>)来查看脚本是否会超过这个点。事实并非如此。

我已经尝试从包含的脚本中调用mail();。我收到邮件了。所以，我再次知道这条路是正确的。它正在被执行，但是它永远不会返回，而且我没有收到任何错误，至少在PHP日志中没有。克伦的工作死了..。

这是一台新服务器。我刚刚将应用程序从PHP5.3.10迁移到PHP7。其他的都能用。

我不认为我会失去记忆。在这个脚本中，我甚至还没有从数据库中获取数据，但这似乎是某种累积的错误，因为当我注释掉这条违规行时，错误会转移到代码的另一个同样令人费解的无声失败中。

是否还有其他有用的测试、日志或环境条件需要查看？我能问网络主机什么吗？

Answer 1

这通常意味着在包含的文件中触发了一些致命错误。如果没有打开所有错误，PHP在包含带有某些致命错误的文件时可能会悄悄地失败。PHP 7会在PHP5.3没有的某些事情上抛出致命错误，例如除以零。如果您无法访问服务器配置来打开所有错误，那么调用一个未定义的函数将无声地失败。您可以尝试将die('test'); __halt_compiler();放在行的开头(从顶部开始)，在第一个<?php标记之后的行中进行调试，并查看它是否加载。如果它确实缓慢地逐行取代(尽管不要切割一个控制结构！)每次重测之后，当它死后，你知道错误在上面的线上。

Answer 2

我相信问题可能是PHP 7的错误。只有当CRON调用它时，代码才会中断，而“修复”是删除关闭的PHP标记?>。虽然很难相信这会是个问题，但我做了很多单元测试，删除了以前的代码，等等，我正在运行PHP7.0.33。在CRON运行时，其他十几个(备份)脚本都没有中断。

Answer 3

作为nzn 指示性，这很可能是由包含的文件触发的错误引起的。从外部看，很难诊断。可能的情况是该文件中的相对include/require。验证这一点的一种方法是在控制台上从不同的位置运行脚本。F可能是在启动cd之前从cron调用chdir(__DIR__)，或者在执行进一步包含之前在主文件中执行chdir(__DIR__)。