我正计划从 Solaris/x86 迁移到 RHEL6。此迁移的一部分是将服务从 SMF 迁移到 RHEL6 等价物，这似乎是新贵。虽然似乎仍然支持 init.d 脚本，但我想利用更复杂的 init 守护程序，特别是对于作业监督（重新启动等）等功能。我想就以下几点收集一些想法：
1) upstart 是否是一个足够的工作主管，即它是否排除了对像 daemontools/supervise 这样的独立管理器的需求？
2) 与典型的 init.d 脚本相比，Upstart 脚本看起来非常简单。如果我将 init.d 脚本移植到 Upstart，是否可以只执行“exec /etc/init.d/myjob start”？这包括 RHEL 安装的程序，如 httpd。
3) upstart 是否对 pid 文件做任何事情，它对进程的分叉模型有什么期望？
4) Upstart 的流程管理方面是否有任何直接的指南……我的意思是控制重启的条件？例如，在进程进入维护状态之前重启进程多少次，或者忽略受监督进程的子进程中的错误/核心转储。
任何其他相关的想法或指南将不胜感激。
TIA
我已经开始运行 cfengine3，使用 cf-execd 以默认的每 5 分钟间隔安排运行 cf-agent。
cf-execd 捕获 cf-agent 的输出（使用 --inform 选项运行），将输出存储在 $WORKDIR/outputs 目录中，并将结果通过电子邮件发送（但前提是它与上次运行不同）。就像你想象的那样，每 5 分钟输出一个文件，这个目录会很快被大量文件填满，预计用户会清理这个目录。
我创建了一个规则，将删除这些超过 3 天的输出文件，但是这产生的问题是每个输出都与前一个不同（因为每次都会删除一个新文件），因此将发送一封电子邮件发送。因此，我从输出目录中的大量文件转到收件箱中的大量电子邮件！
我真正想要的是在修复某些承诺时抑制消息，特别是删除输出目录中文件的承诺。它基本上只会否定该承诺的 -I 选项。或者，如果我可以将时间边界从“现在”更改为固定点（比如每周三），我至少可以将电子邮件数量限制为每周一封。
我对所有文件复制承诺使用“摘要”复制方法，因为我们打包和部署软件的方式，我不能依赖 mtime 来更新文件的标准。由于各种原因，我没有使用客户端-服务器方法和中央配置服务器：而是我们将整个配置模块打包并部署到每个服务器，所以从 cf-engine 的角度来看，源和目标在服务器上是本地的跑步。
我在使用这种方法时遇到的问题是，当它们不同时，源总是会更新目标——这是我大部分时间想要的，通常是因为源已经更新。
但是，像许多其他 cfengine 用户一样，我们正在运行一个操作环境，有时必须立即应用紧急修复 - 这意味着我们没有时间重建和重新部署配置模块，并且修复通常会通过部署一个带有特定更改的压缩包。当然，如果 cf-engine 在 5 分钟后出现并恢复更改，这将是有问题的。
我们想要的是能够对我们的服务器进行小的、增量的更改，而不会恢复它们，直到下一个部署周期复制新的源文件。我们不认为随机文件损坏或错误更改涉及足够的风险来保证 cfengine 不断将部署恢复到其源副本 - 部署紧急修复并让它们保持这种状态直到下一次部署的能力将具有更大的价值和实用性.
所以，毕竟，我的问题是：cf-engine 是否能够检测当文件不同时是源还是目标发生了变化，如果是，它们是一种使用“摘要”复制方法的方法，但仅限于如果源端改变了？我对其他想法和方法也非常开放，因为我对整个配置管理的东西还是很陌生。