什么是停止nagios ndo2db守护进程的正确方法？

什么是杀死Nagios的ndo2db守护进程的正确方法？

当我closuresnagios和ndo2db我做到以下几点：

/etc/init.d/nagios stop
/etc/init.d/ndo2db stop

我在nagios.log看到以下nagios.log ：

 [1311865619]抓到了SIGTERM，关机...
 [1311865619]成功closures...（PID = 12422）
 [1311865619] ndomod：完成关机。
 [1311865619]事件代理模块“/usr/local/nagios/bin/ndomod.o”已成功取消初始化。

但是，/ /etc/init.d/ndo2db stop将以下消息输出到控制台：

ndo2db没有运行…无法停止

如果我做ps -ax | grep nagios ps -ax | grep nagios我仍然看到一个ndo2db进程正在运行：

12381 ? Ss 0:00 /usr/local/nagios//bin/ndo2db -c /usr/local/nagios//etc/ndo2db.cfg

然后我必须手动杀死之前重新启动ndo2db，否则我得到：

 [root @ nag01 nagios]＃/etc/init.d/ndo2db start
启动ndo2db：无法绑定套接字：地址已在使用中
 完成。
 [root @ nag01 nagios]＃

有没有一个更干净的方式来做到这一点？

我在跑：

Nagios 3.2.3从源码build立
NDO Utils 1.4b9从源代码构build
Centreon 2.2.1稳定
Centos 5.5 x64
MySQL 5.5 x64

更新：

我注意到的奇怪的（？）之一是，当ndo2db和nagios运行时，我看到两个ndo2db的实例：

 12753？  Ss 0:00 / usr / local / nagios // bin / ndo2db -c /usr/local/nagios//etc/ndo2db.cfg
 12792？  S 0:00 / usr / local / nagios // bin / ndo2db -c /usr/local/nagios//etc/ndo2db.cfg

这是正常的吗？如果是这样，那么我的猜测是init.d脚本的stop部分只能杀死一个进程？

我find了罪魁祸首 – 这是Centreon的configuration文件生成器。

ndo2db具有从CentreonconfigurationUI中缺less的lock_file设置。

当Centreon生成configuration文件时，它也生成ndo2db.cfg – 但没有lock_fileconfiguration值。

有一个公开的问题：

configuration中没有lock_file字段 – Centreon – ndo2db.cfg

在对源代码进行了ndo2db之后，当ndo2db进程以及没有设置lock_file时候，它忽略了这个并继续执行，并且没有写入包含PID的locking文件。

这当然意味着init脚本中的stop函数将无法识别ndo2db进程ID，因此可能会被终止。

更新：

为了解决这个问题，我手动在centreon数据库的cfg_ndo2db表中添加了一个新列：

 ALTER TABLE `cfg_ndo2db` ADD COLUMN `lock_file` VARCHAR(255) NULL DEFAULT NULL;

然后我用我的ndo2dblocking文件的path填充它：

 UPDATE `cfg_ndo2db` SET `lock_file`='/usr/local/nagios/var/ndo2db.lock' WHERE `id`=1;

这将强制centreon在每次生成configuration时写入lock_file设置。这也似乎生存升级以及，虽然我会经常检查数据库升级脚本，以确保这不作为一个无证修复潜入。