Uploaded image for project: 'Facter'
  1. Facter
  2. FACT-1373

Facter with external fact containing a facter call fork-bombs the node

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: FACT 3.1.4, FACT 3.1.5
    • Fix Version/s: FACT 3.1.7
    • Component/s: Community, PE
    • Environment:

      Standard new install of PE 2015.3.3. RedHat 6.6 and Solaris 10

    • Template:
    • Story Points:
      1
    • Sprint:
      Client 2016-05-18
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Previously, if facter was called from an external fact it would generate endless recursive facter calls and fork bomb the agent. In order to prevent this, we will now detect recursive calls to evaluate external facts, and if we encounter one we will log a warning and stop evaluating external facts.

      To do this, we set an environment variable called 'INSIDE_FACTER' the first time external facts are evaluated and check this variable before we evaluate external facts to ensure it hasn't been set. It is possible that a user may have their own environment variable called 'INSIDE_FACTER' set to true, so anytime we encounter that variable set to true, we log a debug warning.
      Show
      Previously, if facter was called from an external fact it would generate endless recursive facter calls and fork bomb the agent. In order to prevent this, we will now detect recursive calls to evaluate external facts, and if we encounter one we will log a warning and stop evaluating external facts. To do this, we set an environment variable called 'INSIDE_FACTER' the first time external facts are evaluated and check this variable before we evaluate external facts to ensure it hasn't been set. It is possible that a user may have their own environment variable called 'INSIDE_FACTER' set to true, so anytime we encounter that variable set to true, we log a debug warning.

      Description

      If you have an external fact that contains a call to facter, the machine begins to fork-bomb itself and usually control cannot be regained of the system if you cannot quickly get all puppet processes killed.

      Example fact:

      datacenter.sh

      #!/bin/bash
      prefix=`facter ipaddress |awk -F "." '{print $1"."$2"."$3}'`
       
      case "$prefix" in
        10.1.2)
          echo "datacenter=foo"
          ;;
        10.2.3)
          echo "datacenter=bar"
          ;;
        *)
           echo "This is an unknown location."
           ;;
      sac
      

      This outputs the location of a datacenter based on subnet. If this script is run "as is" as an external fact by placing it in /etc/puppetlabs/facter/facts.d and you run "facter datacenter", facter begins to compound upon itself until it consumes all resources on the system, and must be rebooted.

      The workaround I use (provided by Ben Ford) is:

      datacenter.sh

      #!/bin/bash
      prefix=`facter ipaddress --no-external-facts |awk -F "." '{print $1"."$2"."$3}'`
       
      case "$prefix" in
        10.1.2)
          echo "datacenter=foo"
          ;;
        10.2.3)
          echo "datacenter=bar"
          ;;
        *)
           echo "This is an unknown location."
           ;;
      sac
      

      And this works fine.

      Desired result would be that facter would recognize it is running an external fact already, and should assume "--no-external-facts" to prevent the fork-bomb behavior and/or some other mechanism internally to facter that would prevent the fork-bomb.

      ------
      Update
      The resolution of this issue will prevent the fork-bomb condition by performing the following

      1. The recursive condition will be caught
      2. External facts will be skipped
      3. A warning will be presented alerting the user to modify their external fact to call facter with --no-external-facts

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              jerald.sheets@puppetlabs-services.com Jerald Sheets [X] (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support