Jira (FACT-2019) puppet agent -t --debug resolves fact, without --debug it doesn't

0 views
Skip to first unread message

Athanasios Douitsis (JIRA)

unread,
Sep 12, 2019, 8:50:03 AM9/12/19
to puppe...@googlegroups.com
Athanasios Douitsis created an issue
 
Facter / Bug FACT-2019
puppet agent -t --debug resolves fact, without --debug it doesn't
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2019/09/12 5:49 AM
Environment:

FreeBSD 11.2-RELEASE-p14, puppet5-5.5.16, facter-3.14.3.

Priority: Critical Critical
Reporter: Athanasios Douitsis

I use $os[release][major] inside one of my manifests. Running

puppet agent -t

yields the error: Operator '[]' is not applicable to an Undef Value

However, running

puppet agent t --debug---

yields the value correctly and the manifest gets applied okay.

 

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Athanasios Douitsis (JIRA)

unread,
Sep 13, 2019, 6:45:03 AM9/13/19
to puppe...@googlegroups.com
Athanasios Douitsis commented on Bug FACT-2019
 
Re: puppet agent -t --debug resolves fact, without --debug it doesn't

Just to clarify, using the debug flag on the client side, I get:

Debug: Facter: fact "os" has resolved to {
   architecture => "amd64",
   family => "FreeBSD",
   hardware => "amd64",
   name => "FreeBSD",
   release => {
     full => "11.2-RELEASE-p14",
     major => "11",
     minor => "2-RELEASE-p14"
{{   }}}
}.

Which means the fact works correctly with regards to getting the info out of the operating system. Furthermore, other nodes which use older puppet versions such as 4, work correctly. Since the debug flag at the client alters the behaviour, I'd say this is a bug not of the puppetmaster but of the client.

 

Furthermore, I've been playing with some notice messages on the side of the puppetmaster to understand what's being transmitted by the buggy client to the master. Here's what comes across without the debug flag:

os is a Struct[\{'architecture' => String, 'family' => String, 'hardware' => String, 'name' => String}]

and here is what comes across with the debug flag:

{{os is a Struct[{'architecture' => String, 'family' => String, 'hardware' => String, 'name' => String, 'release' => Struct[

{'full' => String, 'major' => String, 'minor' => String}

]}]}}

So as you can see, when running without the debug flag, the nested Struct (the release key) gets swallowed somewhere along the way.

 

 

 

Athanasios Douitsis (JIRA)

unread,
Sep 13, 2019, 7:27:03 AM9/13/19
to puppe...@googlegroups.com

...and, running on the client the command

facter os

yields:

{{{}}
{{ architecture => "amd64",}}


{{ family => "FreeBSD",}}
{{ hardware => "amd64",}}
{{ name => "FreeBSD"}}
}

and the release key is missing. But if I run

facter os --debug

yields:

{{{}}


  architecture => "amd64",
  family => "FreeBSD",
  hardware => "amd64",
  name => "FreeBSD",
{{ release => {}}
    full => "11.2-RELEASE-p14",
    major => "11",
    minor => "2-RELEASE-p14"
{{  }}}
}

I checked with dwatch and both cases (with debug and without) execute the same /bin/freebsd-version command.

So, in a nutshell, without the debug flag the release nested key is somehow lost. This is evidently a bug in facter.

Athanasios Douitsis (JIRA)

unread,
Sep 13, 2019, 9:24:02 AM9/13/19
to puppe...@googlegroups.com

Okay, I think I found the bug.

https://github.com/puppetlabs/leatherman/pull/305

Using the debug flag was slightly altering the process timing, so the signal was not arriving in time to wreak havoc. Without the debug flag, it was able to cause mischief in a more consistent way.

Reply all
Reply to author
Forward
0 new messages