PHP致命错误后进程继续运行

我在cron中每分钟都在运行以下shell脚本，以确保PHP脚本的副本始终在运行：

MY_DIR=`dirname $0`
/usr/local/bin/setlock -n /tmp/newdb.$1.lock /usr/local/bin/php $MY_DIR/background/$1.php

这被称为通过cronjob：

*  *  *  *  *  ~/mysite/background-process.sh new-min-max-dispatcher

它正在运行的php脚本被设计为执行大约需要30分钟的任务，然后退出，之后cron将重新启动进程。这几乎在所有时间都有效，但每隔一段时间，这个过程就不会退出。当脚本在

STDERR

上生成大量输出时，似乎会发生这种情况

但是，我无法通过简单地强制脚本向

STDERR

输出类似的量来重现这种行为。在

ps

中，我可以看到进程和来自crontab的

sh

调用仍在运行。几个月来，我一直在试图弄清楚为什么会发生这种情况，包括在每个while循环中添加额外的代码到

die（）

，如果循环持续的时间超过了合理的时间，请给我发电子邮件

今天我得到了一个重要的证据。在发现进程已经运行了两天并将其终止后，我收到了cronjob通过脚本发送给STDERR的电子邮件，结尾是：

Fatal error: Maximum execution time of 3600 seconds exceeded in /home/myuser/mysite/inc/browser.php on line 102
/home/myuser/mysite/background-process.sh: line 2: 28189 Terminated
/usr/local/bin/setlock -n -x /tmp/newdb.$1.lock /usr/local/bin/

我并不担心PHP脚本达到了它的最大执行时间——这可能会发生。我想知道为什么如果PHP脚本死于致命错误，进程仍然挂在ps中，以及用于启动它的sh命令cron：

myuser 32091  0.0  0.0   8892  1104 ?        Ss   Oct28   0:00 /bin/sh -c ~/mysite/background-process.sh new-min-max-dispatcher 
myuser 32142 46.7  5.2 328788 131920 ?       R    Oct28  63:24 /usr/local/bin/php /home/myuser/mysite/background/new-min-max-dispatcher.php

---

在我看来，php命令应该以致命错误结束，导致setlock完成，background-process.sh脚本完成，整个cronjob完成。我怀疑可能有一些奇怪的事情正在发生，因为流的管道或setlock的一些副作用。我对这两个方面都不太了解，甚至不知道下一步该看哪里。

我建议您下次脚本工作不正常时，请调用strace system linux工具。它将显示哪个系统调用脚本等待/调用。它可能会为您提供一些解决问题的信息。有一个strace调用示例：#strace-p32142 lsof工具可以告诉您为脚本打开了哪些资源