疯狂的crond行为.不断制作失效的 bash 进程

问题描述

我有一个像这样的 crontab:

I have a crontab that looks like:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

0-59 * * * * /var/www/html/private/fivemin/zdaemon.php >> /dev/null &

尽可能简单，对吗?

我刚刚测试的zdaemon.php是:

zdaemon.php which I am just testing with is:

#!/usr/bin/php
<?


while(true){
        sleep(1);
}

?>

无论何时运行，它都会像这样挂起:

Whenever it runs it hangs like:

root     15532  0.0  0.1 57228 1076 ?        Ss   19:09   0:00 crond
root     16681  0.0  0.1 72196 1428 ?        S    21:46   0:00 crond
root     16682  0.0  0.0     0    0 ?        Zs   21:46   0:00 [bash] <defunct>
root     16683  0.0  0.5 54800 5740 ?        S    21:46   0:00 /usr/bin/php /var/www/html/private/fivemin/zdaemon.php
root     16687  0.0  0.1 72196 1428 ?        S    21:47   0:00 crond
root     16688  0.0  0.0     0    0 ?        Zs   21:47   0:00 [bash] <defunct>
root     16689  0.0  0.5 54800 5740 ?        S    21:47   0:00 /usr/bin/php /var/www/html/private/fivemin/zdaemon.php

我整天都在用脑子撞墙.谁看过这个吗?有什么想法吗?

I have been banging my brain against a wall on this all day. Has anyone seen this before? Any ideas at all?

这是参考:Init.d 脚本挂起

推荐答案

僵尸 过程本身并不一定是坏事.它表明 child 进程已经死亡，并且 parent 进程还没有获得它的状态(使用 wait() 或相关的系统调用).

A zombie process is not necessarily a bad thing in itself. It indicates that the child process has died, and the parent process has not yet reaped its status (using wait() or a related system call).

发生的事情如下 - cron 对 stderr 从它启动的脚本感兴趣(以便它可以在脚本失败时通过电子邮件将其发送给您)，因此它创建了一个 pipe，它附加了脚本的 stderr 以写入结束(文件描述符 2).然后 cron 坐在管道的读取端读取，等待脚本退出并读取 eof (read() 零字节)- 然后获取脚本的返回状态.

What is happening is as follows - cron is interested in stderr from the script it starts (so that it can email it to you should the script fail), therefore it creates a pipe which is attaches stderr of the script to write end (file descriptor 2). Then cron sits reading on the read end of the pipe, waiting for the script to exit and read eof (read() of zero bytes) - it then reaps the return status of the script.

在您的示例中，守护进程产生并继承了 stderr 文件描述符，因此当中间 shell 退出(并失效)时，管道由守护进程保持打开状态.因此 cron 永远不会读取 eof 并且因此永远不会获得返回状态.

In your example, the daemon spawned, inherits the stderr file descriptor, and therefore when the intermediate shell exits (and becomes defunct), the pipe is held open by the daemon. Therefore cron never reads eof and hence never reaps the return status.

解决方案是确保守护进程的 stderr 已关闭.这可以通过以下方式实现:

The solution is to ensure that stderr of your daemon is closed. This can be achieved as follows:

0-59 * * * * /var/www/html/private/fivemin/zdaemon.php >> /dev/null 2>&1 &

这会将两者 stdout 和 stderr 写入 /dev/null

which will write both stdout and stderr to /dev/null

这篇关于疯狂的crond行为.不断制作失效的 bash 进程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！