Affects Version/s: None
Fix Version/s: 3.7.3
I have observed that when bootstrapping a 3.7.1 agent to a 3.7.2 hub (I don't think the versions matter much) while trigger_upgrade is defined results in a failed bootstrap and cf-execd is left in a non running state. At this point simply running service cfengine3 start does bring up the services correctly.
This shows that trigger_upgrade is set
root@hub:/var/cfengine/masterfiles# grep -A3 trigger_upgrade controls/3.7/update_def.cf
"trigger_upgrade" or =>
This shows the failed bootstrap
root@host001:/vagrant/packages/agent_deb_x86_64# cf-agent --bootstrap 192.168.33.2
notice: Bootstrap mode: implicitly trusting server, use --trust-server=no if server trust is already established
notice: Trusting new key: SHA=f5428c4237ecfa3613adfb80e590348e4a32c9decec37635af6a8db4c25ddc62
R: This autonomous node assumes the role of voluntary client
R: Updated local policy from policy server
R: Started the scheduler
error: Bootstrapping failed, cf-execd is not running
Bootstrap currently executes update.cf and that fails for some reason. I suspect because perhaps sys.policy_hub is yet to be defined. I can't really tell.
I was however able to work around the situation by defining a class based on the presence or non presence of a cf-agent process using the --bootstrap or -B option. Then use the non presence of that to guard the upgrade policy from being activated.
At a minimum I think it would be better to at lease define bootstrap_mode on that execution of update.cf, and use that class to guard the upgrade. I think it would be more reliable than scanning the process table, but open to suggestions.
And even better, I think it makes more sense to just not execute update.cf from failsafe/bootstrap as suggested in #7660.