疯狂crond的行为。不断倒闭的制作过程中的bash [英] Insane crond behavior. keeps making defunct bash processes

问题描述

我有一个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 &

越简单越好，对吧？

Simple as possible, right?

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?

这是一个参考：<一href=\"http://stackoverflow.com/questions/3589786/init-d-script-hanging\">http://stackoverflow.com/questions/3589786/init-d-script-hanging

推荐答案

一个的僵尸的过程不一定本身是一件坏事。它表明的孩子的进程已经死亡，的父的进程还没有获得它的状态（使用等待（）或相关的系统调用）。

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 是有意的标准错误的从它开始（以便它可以通过电子邮件发送给您应该脚本脚本失败），因此它创建一个管道的是脚本编写结束（文件描述符2）华武官的标准错误的。然后的cron 坐在阅读管道的读端，等待脚本退出和阅读的 EOF 的（阅读（ ）的零字节） - 它，然后收获脚本的返回状态

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.

在你的榜样，守护进程催生，继承的标准错误的文件描述符，因此当中间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.

解决方案是确保的标准错误的守护进程的关闭。这可以实现如下：

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 &

这会写的两个 标准输出的和的标准错误到的/ dev / null的

这篇关于疯狂crond的行为。不断倒闭的制作过程中的bash的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！