php - 什么会导致PHP脚本在创建文本变量时停止运行？

Question

我遇到了几个月来一直试图追踪的最奇怪的问题。我添加了几行调试代码，这些行在基于MySQL的日志中创建日志条目，结果毫无意义。

基本上，脚本有时只是停止。有时，它是随机执行的，然后在同一位置进行了十二次，然后可能一直持续到下一次。

更多细节:

每隔15分钟，我就会遍历一个客户端列表，每个客户端都有一个需要解析和收集电子邮件的数据列表。如果此脚本的先前版本已在运行(即，存在小于5分钟的日志条目)，则不会再次执行该脚本。因此，如果我看到日志条目的中断时间超过了几分钟，然后在第一次启动后的15分钟内又重新启动了一次，则我知道有问题。日志中最奇怪的情况如下:

我将要为客户端X创建数据库查询的日志放入日志中。然后，我使用SQL代码创建了一个变量，该变量包含客户端ID和星期几(date("l", strtotime("now")))。然后，我记录该查询已成功创建。请注意，查询仅存在于PHP变量中，尚未提交给MySQL!

因此，让我给您一个例子，说明我在日志中看到的内容:

3:00:00 pm-(脚本开始)

3:00:00 pm-(通过客户端循环)

3:00:04 pm-(它已经通过了一些客户端，现在正在客户端20上工作)

3:00:04 pm-为客户端20

创建查询

(如果在至少5分钟内没有任何日志条目，日志将在此处结束，直到15分钟后自动重新启动脚本为止)

3:15:00 pm-(脚本开始)

3:15:00 pm-(它通过客户端循环)

3:15:04 pm-(它已经通过了一些客户端，正在跳过客户端20，因为显然有问题，现在正在客户端21上工作)

3:15:04 pm-为客户端21

创建查询

3:15:04 pm-为客户端21

成功创建查询

(如果在至少5分钟内没有任何日志条目，日志将在此处结束，直到15分钟后自动重新启动脚本为止)

3:30:00 pm-(脚本开始)

3:30:00 pm-(通过客户端循环)

3:30:04 pm-(它已经通过了一些客户端，现在正在客户端20上工作)

3:30:04 pm-为客户端20

创建查询

然后冲洗并重复。现在，要花费几个小时，它会在为客户端20创建查询之前失败与在为客户端21创建查询之后失败之间进行切换。然后，突然之间，它可能一直贯穿其余的客户端。然后，脚本再次启动，并将继续相同的怪异循环。每天大约会有另外一两个客户发生这种情况。

查询非常简单，如下所示:

$sql = "
select fldClientName
from client
where fldClientId = $clientId
and fldEmail".date("l", strtotime("now"))." = 1
";

基本上，如果今天是星期一，则应检查fldEmailMonday是否设置为1，以告知我们该客户今天需要通过电子邮件发送。

这适用于我们众多的客户，但它只是随机地陷入每天变化的一两个客户中。再一次，这发生在 $sql提交给MySQL之前!我们陷入了创建 $sql变量的困境。

当然，实际查询比我在这里写的要复杂得多，但是 $clientId和 date("l", strtotime("now"))是静态文本中仅有的可变部分。

此外，多年来，我们遇到了同样的问题(我现在才开始对其进行更多跟踪)，到现在，我们已经经历了三台PHP服务器和两台MySQL服务器-而我们仍然遇到同一问题，因此我们可以肯定地确定这不是硬件问题(例如内存或硬盘驱动器)。

我不知道这是否可能是问题，但是此脚本由在lynx中启动它的cron作业运行。它是在我编写代码之前建立的，我不知道它的原因。每当我们手动运行它时(我通常使用 php index.php而不是 lynx hostname://index.php)，它似乎永远不会失败。

那么Lynx可能会出现问题吗？如果是这样，为什么它会在70％的时间内工作，否则会失败？为什么是随机性？

还是我应该找出一个PHP问题？我们正在运行5.3.2版(是的，有些旧，但是除非绝对必要，否则我们的服务器管理员不希望将其弄乱)。

我猜想使用了Lynx，所以我们得到了Apache日志(顺便说一句，它是空的，除了我现在想摆脱的一些过时的代码警告)，而且我猜想如果我运行 php index.php，我没有apache日志。也许我缺少另一个日志文件，可能对您有所帮助？

同样，也可能不是日志代码本身引起的，因为它仅提交纯静态文本和在创建SQL代码之前建立的客户端ID。

该脚本在很多地方都失败了，但这对我来说真的没有任何意义。

关于什么会导致这样的事情有任何想法吗？

我还有什么想法可以找到答案吗？我的意思是，我在创建变量之前和之后都在进行日志记录，并且该日志记录在两者之间消失-现在确定我可以在此处记录的数量还更多...

Answer 1

总结一下对话，我的主要策略是简化cron调用中涉及的软件组件的数量。因此，这意味着从:

Cron -> Lynx -> Apache -> Script

至

Cron -> Script

如果新方法仍然存在问题，则至少要排除两个组件(而且可能会更快)。从您的评论看来，这已解决了问题；如果是这样，那太好了。

在此我要重申的一个更广泛的观点是，虽然一个棘手的问题可能会引起关注，但出于成本原因，有一点最好是用另一种方法解决该问题。这可能是这样的情况，而Lynx失败的谜团可能仅会持续存在!