提交补丁以修复LP:#600941造成的所有损坏的最佳方法是什么？
我问是因为 LP:#600941 被放入了目前仍然支持的每个版本的 Ubuntu。我应该选择一个特定的版本并运行ubuntu-bug它吗？该版本应该是 LTS 还是 Oneiric 或 Precise（如果需要，我如何获得 Precise？）
故事是在它被推出后，我们所有的系统都开始经历 Nagios nrpe 重启失败。
命令像 /etc/init.d/nagios-nrpe-server restart
会导致 nrpe 停止但不会重新启动。
我将其追溯到/etc/init.d/nagios-nrpe-server脚本调用start-stop-daemon.
问题是/etc/init.d/nagios-nrpe-server脚本中的“停止”节首先调用 start-stop-daemon，它将 SIGTERM 发送到 nrpe，然后只等待一秒钟。
如果此时 nrpe 尚未退出，pid 文件仍将存在，/etc/init.d/nagios-nrpe-server脚本将删除它。
更糟糕的是，如果/etc/init.d/nagios-nrpe-server restart使用 pid 文件，不仅会删除 pid 文件，而且如果 nrpe 守护进程仍然延迟关闭，则重新启动 nrpe 的尝试将失败。
在这些情况下尝试启动将失败，因为 nrpe 仍将绑定到套接字，并且第二次尝试绑定将导致 nrpe 启动中止。
他们应该想知道为什么会有关于“有时 pid 文件没有被删除”的评论。
他们应该在负载较重并因此 nrpe 响应时间较慢的系统上进行测试。
解决方法是--retry 10在调用中添加或这样的start-stop-daemon ... --stop ...
谢谢
背景故事：
确定当使用 lxc 容器虚拟机时，Nagios nrpe 关闭脚本在容器主机上运行时会杀死容器内的 nrpe 进程。这是通过更改脚本以使用 pidfiles 而不是搜索 nrpe 进程的进程表来解决的。
遗憾的是 start-stop-daemon 是一个 C 程序，它是由翻译 Perl 脚本产生的，它显示出来。start-stop-daemon.c 中有太多的全局变量，尽管有一些不错的注释块，但很少有注释可以解释变量名背后的意图，例如“schedule”（字符串“schedule”出现在许多上下文。） start-stop-daemon 的手册页强烈建议，除非您使用“--retry”选项，否则 start-stop-daemon 程序可能会在它发送信号以实际调用 exit() 并终止的进程之前返回，但是它实际上并没有用简单的英语说明这一点。
start-stop-daemon 的迟钝很可能是脚本的“固定”版本包含可疑注释的原因，该注释表明有时 pid 文件尚未删除。我很容易理解为什么有人不明白他遗漏了 --retry 选项。当脚本被赋予“重启”选项时，这个错误也会导致失败；nrpe 守护进程将关闭但不会再次启动。
我有没有提到自从应用更新我们的 nrpe 服务器开始一遍又一遍地崩溃？修复这就是我做这项工作的原因。
我一直在努力修复此修复程序。你可以在这个 PPA 中看到我目前的工作。
实际问题：
lucid-updates中nagios-nrpe-server的上游版本号为
2.12-4ubuntu1.10.04.1
我的 PPA 使用此版本号
2.12-4ubuntu1.10.04.1.1~ppa1~lucid1
我在这里检查规则并使用这个测试程序，我相信我在 PPA 中使用的版本号大于 lucid-updates 中的版本号，但当我运行时：
须藤添加-apt-repository ppa:nutznboltz/nrpe-unbreak-lp-600941 sudo apt-get 更新 sudo aptitiude dist-upgrade
未安装替换包。
我能够使用安装它
sudo aptitude install nagios-nrpe-server=2.12-4ubuntu1.10.04.1.1~ppa1~lucid1
谁能解释这种行为？为什么我的版本号看起来没有“aptitude dist-upgrade”更大？
谢谢
$ cat /etc/apt/preferences 包裹： …