Uploaded image for project: 'CFEngine Community'
  1. CFEngine Community
  2. CFE-832

bundle return value problem and spurious locking message

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.x
    • Component/s: Evaluation
    • Labels:
      None
    • Found in version (details):
      CFEngine Core 3.6.0a1.0eaa92a

      Description

      Observed in master branch and 3.5.1; reported on help-cfengine initially and confirmed by me. This is a very common use pattern for Design Center so it's worrying.

      policy:
      <pre>
      body common control
      {
      bundlesequence =>

      { 'main' }

      ;
      }

      bundle agent main

      { methods: any:: "callme" usebundle => callme, useresult => "maybe", ifvarclass => "linux"; reports: inform_mode:: "callme returned defined = $(maybe[retkey])"; "callme could not run because it requires classes linux" ifvarclass => "inform_mode.!(linux)"; } bundle agent callme { reports: "this is the return value!!!" bundle_return_value_index => "retkey"; }

      </pre>

      Behavior (run as root):
      <pre>

      1. cf-agent -KI -f ~/Dropbox/cf/test/test-spurious-locking-messages.cf
        2013-08-02T11:15:53-0400 notice: R: callme returned defined = this is the return value!!!
      1. cf-agent -I -f ~/Dropbox/cf/test/test-spurious-locking-messages.cf
        2013-08-02T11:19:08-0400 info: Lock lock.callme.reports.bundle_return_value_index.-heechee.this_is_the_return_value____21_300_MD5=0de4b2c491385d411364156e301ca9e7 expired (after 1/1 minutes)
        2013-08-02T11:19:08-0400 notice: R: callme returned defined = this is the return value!!!
      1. cf-agent -I -f ~/Dropbox/cf/test/test-spurious-locking-messages.cf
        2013-08-02T11:19:14-0400 notice: R: callme returned defined = $(maybe[retkey])
      2. cf-agent -I -f ~/Dropbox/cf/test/test-spurious-locking-messages.cf
      1. cf-agent -V
        CFEngine Core 3.6.0a1.0eaa92a

      </pre>

      So there are two issues which may be related:

      1. the lock message is spurious and shows up in outputs/previous without the @-I@ flag. Should be verbose I think.
      2. when locks are respected, the second run's dereferencing of the bundle return value @maybe[retkey]@ fails, although it should have the same value as the first time.

        Attachments

          Activity

            People

            • Assignee:
              a10025 Volker Hilsheimer (Inactive)
              Reporter:
              jiraadmin Old User (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel