Icinga2监控系统中僵尸进程问题的分析与解决

问题背景

在Icinga2监控系统中，当系统负载极高时，经常会出现监控检查超时后被终止的进程变成僵尸进程（defunct状态）的情况。这些僵尸进程会一直存在，直到Icinga2守护进程重启才会被清理。

问题现象

通过系统命令可以观察到类似以下的僵尸进程：

nagios    143808  107103  0 Feb19 ?        00:00:00 [check_systemd_s] <defunct>
nagios    143809  107103  0 Feb19 ?        00:00:00 [check_http] <defunct>

同时，Icinga2日志中会记录如下信息：

[2025-02-21 05:14:50 +0000] warning/Process: Terminating process 196844 ('/usr/lib/nagios/plugins/check_http' ...) after timeout of 60 seconds
[2025-02-21 05:14:50 +0000] warning/Process: Killing process group 196844 ('/usr/lib/nagios/plugins/check_http' ...) after timeout of 66 seconds
[2025-02-21 05:14:51 +0000] warning/Process: Couldn't kill the process group 196844 ('/usr/lib/nagios/plugins/check_http' ...): [errno 3] No such process

技术分析

通过对Icinga2源代码的分析，发现问题出在lib/base/process.cpp文件中的DoEvents函数。当监控检查超时时，系统会先发送SIGTERM信号，6秒后如果进程仍未终止，则发送SIGKILL信号。

在系统负载极高的情况下，可能出现以下时序问题：

1. 发送SIGTERM信号成功
2. 进程在6秒超时前自行终止
3. 系统尝试发送SIGKILL信号时，进程已不存在，返回ESRCH错误(errno 3)
4. 由于这个错误，系统设置了could_not_kill标志
5. 由于could_not_kill标志被设置，系统跳过了waitpid调用
6. 最终导致子进程状态未被回收，形成僵尸进程

解决方案

通过修改代码逻辑，当kill系统调用返回ESRCH错误时，不设置could_not_kill标志，这样系统仍会执行waitpid调用，确保子进程状态被正确回收。

具体修改如下：

1. 在kill调用返回错误时，检查错误码是否为ESRCH
2. 只有当错误码不是ESRCH时才设置could_not_kill标志
3. 其他情况下保持原有逻辑不变

验证结果

经过一周的测试验证，该解决方案有效解决了僵尸进程问题。测试中观察到两种场景：

1. 正常kill行为：进程被成功终止
2. ESRCH错误场景：进程已自行终止，但仍能正确回收进程状态

技术建议

对于类似监控系统的高负载环境，建议：

1. 合理设置检查超时时间，避免频繁超时
2. 监控系统资源使用情况，及时扩容
3. 定期检查系统进程状态，及时发现并解决问题

该问题的解决不仅修复了僵尸进程问题，也提高了Icinga2在高负载环境下的稳定性。