When you run facter it will start by trying to load all facts, e.g. Facter::Util::Collection.load_all. This walks facter’s search path, calling Kernel.load(file) on each *.rb file. When facter loads simple facts of the form:

Facter.add(:factname) do
  ...
end

it registers a Facter::Util::Fact object, and appends to its list of resolutions for that fact. In other words, we don’t actually try to evaluate the fact.

However, some facts resolve other facts outside of their add block. For example, in ec2.rb, we effectively do:

if !!(Facter.value(:macaddress) =~ %r{^[dD]0:0[dD]:})
  Facter.add(:ec2) do
    ...
  end

The key issue here, is that we try to resolve the macaddress fact before we’ve loaded the macaddress.rb file and registered a Facter::Util::Fact for it (because ec2.rb comes before macaddress.rb).

As a result, in Facter::Util::Collection.load(name), we call:

    # Try to load the fact if necessary
    load(name) unless @facts[name]

where load(name) causes all external facts to be evaluated:

  def load(name)
    internal_loader.load(name)
    external_loader.load(self) # <---- HERE

But the fun doesn’t stop there. The :macaddress fact has multiple resolutions, some confined by :osfamily, others :operatingsystem, each of which triggers all external facts to be evaluated. And actually :osfamily depends on :operatingsystem, so that adds another round of evaluating external facts.

The same issue also occurs when evaluating blockdevices.rb as that depends on the :kernel fact:

if Facter.value(:kernel) == 'Linux'
  ...
  Facter.add(:blockdevices) do

In the short-term, we should ensure we only load external facts once.

• Merged to stable in e0bdf2873c8ade9d7a06878d66e6bca902417515
• Merged to master in 20b0ee56b1c35c9ca75b98c58d66c93ec61834fc

Release in Facter 1.7.4-rc1