The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
--- and \\ prepended to environment
|Affected Puppet version:||2.6.2||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
I’ve recently enabled storeconfigs (PostgreSQL backend), and am using them to export Nagios resources. It’s been working for a few days, then I merged a branch into production that should have added a monitor to check that state.yaml is being touched on clients. Later, nothing had picked up the change. Looking in syslog on the puppetmaster, I find entries like this (this is just for one host during the failure):
Nov 12 13:15:02 puppet puppet-master: Compiled catalog for rt in environment —– “—– production” in 0.12 seconds Nov 12 13:45:07 puppet puppet-master: Compiled catalog for rt in environment —– “—– \”—– \\“—– production\\”\“” in 0.04 seconds
Some of them are more absurd:
Nov 12 14:01:21 puppet puppet-master: Compiled catalog for nagios in environment —– “—– \”—– \\“—– \\\\”—– \\\\\\\\“—– \\\\\\\\\\\\\\\\”—– \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\“—– \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\”—– \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\“—– \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\”—– \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
It looks like for each run it’s taking the previous value, escaping “ and \, quoting it with ”, and prepending —–.
Anyhow, I restarted puppetmaster and things seem back to normal.
Looking a in the puppet database, I do notice that for each row in the hosts table, a “—–” is prepended to the environment. So, for a host that should be in “production”, the environment column is set to “—– production”. This is for hosts which have checked in since the restart; those that have not yet checked in have longer strings with more —– and \.
I can only guess this has something to do with features that allow setting the environment on the server side; I’m not (intentionally) using those features. Some of my clients have an environment explicitly set in puppet.conf, but most just use the default production. I don’t think those with an explicit environment avoided the failure.