我的问题：在服务器（策略中心）上手动创build/更新cfengine3策略，并且客户端定期（每〜5分钟）将这些策略从服务器：/ var / cfengine / masterfiles中分别转移到它们各自的某个客户端：/ var / cfengine /投入（他们应该）。
但是这种行为有时会不一致 。 服务器中的更新文件可能不会反映到客户端，直到稍后。 它可以> 30分钟或更长，直到它突然“看到”更新。 特别是如果我创build/更新发生在./masterfiles下的子目录中。
我已经用tcpdump检查过每个客户端实际上每5分钟通过cfengine端口（5308）与主服务器进行通信。
我看不到政策文件没有更新的原因。
任何人都经历过相同或有build议？ 谢谢。
（刚刚升级到cfengine 3.3.1，CentOS / Fedora隔离环境混合 – 其余networking在cf2上运行愉快）。
大卫，
更新的文件是否被复制，并且本地的cf-agent不会对更改做出反应？ 还是更新的文件不被复制，直到更晚？
我能想到的一个原因就是系统之间的时钟不同步。 检查/ var / cfengine / inputs / cf_promises_validated – 在上次在服务器上检查承诺时填充此文件，客户端使用此时间戳重新加载其本地策略。
您可能还想在CFEngine帮助论坛发布您的问题，CFEngine专家将会看到这个问题。
大卫，
我也怀疑时钟倾斜，像迭戈。 在http://cfengine.com/blog/cfengine-330-release-notessearchcf_promises_validated这可能会给你一些资源。 关键是您的failsafe.cf中的复制承诺。
你提到你刚把CFEngine升级到3.3.1。
在3.3.1中的/ var / cfengine / masterfiles / cf_promises_validated中有一个新的时间戳（以前的版本是我猜的空白文件），这意味着我们可以改变一种方法来将文件从“mtime”复制到“digest”电streamfailsafe.cf以避免系统时钟问题。 另请参见/var/cfengine/share/CoreBase/failsafe.cf，正文copy_from u_rcp已经具有“摘要”复合主体。
作为其他人，我怀疑时钟偏斜。 检查你的时间。 您还可以删除远程代理上/ var / cfengine /input中的cf_promises_validated文件。 然后，它将看到策略中心上/ var / cfengine / masterfiles中的cf_promises_validated文件是不同的，并将继续完整的策略更新。
从3.3.0开始，cf_promises_validated应包含date时间标记，以便我们不依赖适当的时间同步进行策略更新。
如果使用默认引导策略，请检查您的failsafe.cf。
3.3.1或3.3.0的策略（不确定是哪一个产生了我所看到的故障安全）有一个承诺，使用u_rcp来更新cf_promises_validated文件（如果需要的话）的句柄“check_valid_update”。 如果它修复承诺，那么它将引发validated_updates_ready类/上下文，其中处理update_files_inputs_dir的承诺受限制，以更新策略的其余部分。 检查正文copy_from u_rcp用于compare属性的内容。 如果它的摘要，那么它应该使用文件的内容，而不是只有它的时间戳。