URGENT : cfengine community skipping bundles

Rama

unread,

Dec 4, 2016, 8:01:08 PM12/4/16

to help-cfengine

We continue to encounter this issue with community versions in our current production.

Nothing related comes in a google search. The enterprise version doesn't appear to have this issue in our testing so far.

We have this issue in a large production installation with versions 3.6.5 as well as 3.2.4-1 on linux flavors.

We observe that every alternate log in the outputs folder is much smaller than a full run. Checking the contents of the "shorter" logs leads us to conclude that most bundles (other than the common bundles) are skipped every alternate run, e.g.,

________________

-rw------- 1 root root 50117 Dec 5 07:08 cf_fpdg_92101132__1480881683_Mon_Dec__5_07_01_23_2016_407a7490

-rw------- 1 root root 2318 Dec 5 07:30 cf_fpdg_92101132__1480882901_Mon_Dec__5_07_21_41_2016_407a7490

-rw------- 1 root root 12941 Dec 5 07:48 cf_fpdg_92101132__1480884119_Mon_Dec__5_07_41_59_2016_407a7490

-rw------- 1 root root 40659 Dec 5 08:10 cf_fpdg_92101132__1480885277_Mon_Dec__5_08_01_17_2016_407a7490

-rw------- 1 root root 16587 Dec 5 08:31 cf_fpdg_92101132__1480886495_Mon_Dec__5_08_21_35_2016_407a7490

-rw------- 1 root root 2126 Dec 5 08:50 cf_fpdg_92101132__1480887714_Mon_Dec__5_08_41_54_2016_407a7490

_____________________________

Is there something obvious that we could try, in order to overcome this ? our schedule is set as follows in executor control :

________

body executor control

{

any::

splaytime => "2";

schedule => { "Min00", "Min20", "Min40" };

#agent_expireafter => "15";

#Default:

#schedule => { "Min00", "Min15", "Min30", "Min45"};

.....

_____________________________________

Aleksey Tsalolikhin

unread,

Dec 4, 2016, 9:39:10 PM12/4/16

to Ramakant Duggal, help-cfengine

Hi Rama! Is turning on verbose mode for a couple of runs possible? In body agent control? We might get a clue there.

This email is confidential. If you have received this email in error please notify us immediately by return email and delete this email and any attachments.
VIX accepts no liability for any damage caused by this email or any attachments due to viruses, interference, interception, corruption or unauthorised access.

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengine+unsubscribe@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

Aleksey Tsalolikhin

unread,

Dec 4, 2016, 11:17:38 PM12/4/16

to Ramakant Duggal, help-cfengine

I hesitate to speculate without seeing the code base, but I believe verbose output would help here.

I suspect cfengine will tell you why it's skipping promises - e.g., ifelapsed lock, or inapplicable context.

The bit about agent bundles getting skipped is odd.

On Dec 4, 2016 6:39 PM, "Aleksey Tsalolikhin" <ale...@verticalsysadmin.com> wrote:

Hi Rama! Is turning on verbose mode for a couple of runs possible? In body agent control? We might get a clue there.

Ramakant Duggal

unread,

Dec 5, 2016, 1:40:01 AM12/5/16

to Aleksey Tsalolikhin, help-cfengine

Hey Aleksey,

Here is the verbose out put : out_sel is the one where a particular promise (a command promise). I made some attempt to isolate it in a simple bundle and reproduce it with no success. So I will have cite some of the actual policy fragments and the actual output logs from a test environment with same policies. Problem likely occurs only with all the complexity of other bundles present.

Notice how in the agent run where the promise was run, you see the command 'egrep -q .....' being run :

____________

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

cf3> -> Promiser string contains a valid executable (/bin/egrep) - ok

cf3>

cf3> .........................................................

cf3> Promise handle:

cf3> Promise made by: /bin/egrep -q "^ *(ALL|All|all$) *|^ *92100942 *,?|, *92100942 *,|, *92100942 *$" /var/lib/cfengine3/inputs/config/fpds/terminals_to_upgrade

cf3> .........................................................

cf3>

cf3> -> Executing '/bin/egrep -q "^ *(ALL|All|all$) *|^ *92100942 *,?|, *92100942 *,|, *92100942 *$" /var/lib/cfengine3/inputs/config/fpds/terminals_to_upgrade' ...(timeout=-678,owner=-1,group=-1)

cf3> -> (Setting umask to 77)

cf3> -> Command related to promiser "/bin/egrep -q "^ *(ALL|All|all$) *|^ *92100942 *,?|, *92100942 *,|, *92100942 *$" /var/lib/cfengine3/inputs/config/fpds/terminals_to_upgrade" returned code defined as promise kept (0)

cf3> ?> defining promise result class am_selected_for_upgrade

cf3> -> Completed execution of /bin/egrep -q "^ *(ALL|All|all$) *|^ *92100942 *,?|, *92100942 *,|, *92100942 *$" /var/lib/cfengine3/inputs/config/fpds/terminals_to_upgrade

_______________________________________

This is not seen in the run where the promise was skipped.

Now let's look at the output where it didn't;t run :

_______________

f3> =========================================================

cf3> commands in bundle check_upgrade_target_list (3)

cf3> =========================================================

cf3>