我有一些进程显示为<defunct> in top (and ps）。我从真实的脚本和程序中总结了一些东西。
In my crontab:
* * * * * /tmp/launcher.sh /tmp/tester.sh
的内容launcher.sh（当然标记为可执行）：
#!/bin/bash
# the real script does a little argument processing here
"$@"
的内容tester.sh（当然标记为可执行）：
#!/bin/bash
sleep 27 & # the real script launches a compiled C program in the background
ps显示以下内容：
user 24257 24256 0 18:32 ? 00:00:00 [launcher.sh] <defunct>
user 24259 1 0 18:32 ? 00:00:00 sleep 27
注意tester.sh没有出现——它在启动后台作业后就退出了。
为什么launcher.sh留在周围，标记<defunct>？它似乎只有在启动时才会这样做cron——当我自己运行时就不会了。
附加说明：launcher.sh是其运行的系统中的通用脚本，不易修改。其他的事情（crontab, tester.sh，甚至是我运行的程序sleep）可以更容易地修改。
因为他们不是一个主题wait(2)系统调用。
由于将来可能有人等待这些进程，因此内核无法完全摆脱它们，否则将无法执行wait系统调用，因为它不再有退出状态或存在的证据。
当您从 shell 启动一个程序时，您的 shell 会捕获 SIGCHLD 并执行各种等待操作，因此任何东西都不会长期失效。
但 cron 并不处于等待状态，它正在睡眠，因此失效的子进程可能会停留一段时间，直到 cron 醒来。
Update:回复评论...
唔。我确实设法重复了这个问题：
PPID PID PGID SESS COMMAND
1 3562 3562 3562 cron
3562 1629 3562 3562 \_ cron
1629 1636 1636 1636 \_ sh <defunct>
1 1639 1636 1636 sleep
所以，我认为发生的事情是：
- cron forks 和 cron child 启动 shell
- shell (1636) 启动 sid 和 pgid 1636 并开始睡眠
- shell 退出，SIGCHLD 发送到 cron 3562
- 信号被忽略或处理不当
- shell turns zombie. Note that sleep is reparented to init, so when the sleep exits init will get the signal and clean up. I'm still trying to figure out when the zombie gets reaped. Probably with no active children cron 1629 figures out it can exit, at that point the zombie will be reparented to init and get reaped. So now we wonder about the missing SIGCHLD that cron should have processed.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
