Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My problem: cfengine3 policies are manually created/updated on the server (policy hub), and the clients regularly (every ~ 5 minutes) pull those from the server:/var/cfengine/masterfiles to their respective someclient:/var/cfengine/inputs (as they should).

But this behaves inconsistently some times. An updated file in the server may not be reflected in the clients until a good while later. It can be > 30 minutes or more until it suddenly "sees" the update. This happens especially if what I have created/updated is in a subdirectory under ./masterfiles.

I have checked with tcpdump that each client is in fact communicating with the master server via the cfengine port (5308) every 5 minutes.

I cannot see the reason why the policy files are not updated then.

Any one has experienced the same or has a suggestion ? Thanks.

(Just upgraded to cfengine 3.3.1, mixed CentOS/Fedora isolated environment - the rest of the network runs happily on cf2).

share|improve this question


Are the updated files being copied, and the local cf-agent doesn't react to the changes? Or are the updated files not being copied until much later?

The one reason I can think off the top of my head is that the clocks between the systems are out of sync. Check /var/cfengine/inputs/cf_promises_validated - this file is populated with the last time the promises were checked on the server, and the clients reload their local policies using this timestamp.

You may also want to post your question in the CFEngine Help forum, where it's bound to be seen by a larger number of CFEngine experts :)

share|improve this answer
Thanks for the answer ! Clocks were off by some 30". The files were being copied, but much later. After making hosts listen to the same ntp server now they are totally in sync and the files get copied timely. – David Ramirez May 10 '12 at 15:05
I see you found it was a time skew. You can should be able to update your failsafe or update policy to use digest since now cf_promises_validated now contains a timestamp instead of relying on the mtime of the file. See my answer below for more detail. – Nick Anderson May 10 '12 at 15:23


I also suspect clock skew, like Diego. Search for cf_promises_validated at which may give you some resources. The key are the copy promises in your

share|improve this answer

You mentioned you just upgraded your CFEngine to 3.3.1.

There is a new timestamp in /var/cfengine/masterfiles/cf_promises_validated in 3.3.1 (previous version is a blank file I guessed) which means we can just change a way to copy the file from "mtime" to "digest" in your current to avoid system clock problem. See also /var/cfengine/share/CoreBase/, body copy_from u_rcp already has "digest" compound body.

share|improve this answer

As others I suspect clock skew. Check your times. You can also delete the cf_promises_validated file in /var/cfengine/inputs on the remote agent. Then it will see that the cf_promises_validated file in /var/cfengine/masterfiles on the policy hub is different and will proceed with a full policy update.

As of 3.3.0 cf_promises_validated should contain a datetime stamp so that we aren't relying on proper time sync for policy updates.

Check your if you are using the default bootstrap policy.

The policy as of 3.3.1 or 3.3.0 (unsure which generated the failsafe I am looking at) has a promise with handle "check_valid_update" that uses u_rcp to update the cf_promises_validated file if necessary. If it repairs the promise, then it raises the validated_updates_ready class/context which the promise with handle update_files_inputs_dir is restricted on to update the rest of the policy. Check in body copy_from u_rcp what is used for the compare attribute. If its digest then it should be using the content of the file instead of just the timestamps on it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.