Ask Your Question

Issue with stdlib and basemodulepath on clients [closed]

asked 2015-02-26 13:18:09 -0500

jlent gravatar image

updated 2015-02-27 09:44:30 -0500

I'm seeing some weird behavior on multiple hosts after installing the stdlib module on all 3 of my puppet masters (into /usr/share/puppet/modules). The installation itself wasn't a problem. Worth mentioning is that this is the only module installed into that location.

As I understand it, /usr/share/puppet/modules is a default modulepath (along with /etc/puppet/modules). We have many different environments, however, so I had to change the respective environment.conf files to the following in order for that global path to be honored: modulepath = services:modules:$basemodulepath

Without that edit, hosts basically complain about standard lib (e.g. function file_line not found). With that edit, using stdlib works as expected. However, a byproduct is that there are constant addition and removal of files in /var/lib/puppet/lib/ (see below). The behavior alternates between adding and removing, with approximately 1 in 4 manual runs completing cleanly. This just keeps repeating over and over.

The only sure-fire way to make it stop is to revert the change to environment.conf, which then prohibits use of stdlib.

The masters, running Debian Wheezy, are running 3.7.2-1puppetlabs1. The Debian Wheezy clients are running 3.7.4-1puppetlabs1, and the RHEL6 clients are running puppet-3.7.4-1.el6.noarch. Both of those OS' exhibit this same behavior.

Any ideas? It crossed my mind that the clients are on a higher rev of puppet, but it's not too far beyond the master.

foo:/etc/puppet# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Notice: /File[/var/lib/puppet/lib/puppet/face]/ensure: created
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/pdbstatusquery.rb]/ensure: defined content as '{md5}c61372b06340a6fee1bf492989368cd2'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/pdbfactquery.rb]/ensure: defined content as '{md5}6bc06fa7c5fecca1f09e19b50a84ae37'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/query_nodes.rb]/ensure: defined content as '{md5}4566604125199f885ce8bc23addb519f'
Notice: /File[/var/lib/puppet/lib/puppet/face/query.rb]/ensure: defined content as '{md5}4906ba22e9af79c2c84871398d799424'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/pdbresourcequery_all.rb]/ensure: defined content as '{md5}4555b8fed1e30051c17770bac2329465'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/query_facts.rb]/ensure: defined content as '{md5}7c9917e4a43d8cfea695bbf6b0889746'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/pdbnodequery.rb]/ensure: defined content as '{md5}8c14e9cea5cf2623580dc588cf70d80f'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/pdbresourcequery.rb]/ensure: defined content as '{md5}1a2040b64c1a7e4f6c6c5909b4b0f5e0'
Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/query_resources.rb]/ensure: defined content as '{md5}5816bbb8b0210c81cf5f02dc29bd2f86'
Notice: /File[/var/lib/puppet/lib/hiera]/ensure: created
Notice: /File[/var/lib/puppet/lib/puppet/application]/ensure: created
Notice: /File[/var/lib/puppet/lib/puppet/application/query.rb]/ensure: defined content as '{md5}6f9a79d593677f210fe754cedcf77fa2'
Notice: /File[/var/lib/puppet/lib/puppetdb]/ensure: created
Notice: /File[/var/lib/puppet/lib/puppetdb/astnode.rb]/ensure: defined content as '{md5}22004c25bfdff10e78e3d6b579dc6045'
Notice: /File[/var/lib/puppet/lib/puppetdb/grammar.racc]/ensure: defined content as '{md5}76cd28f9ea5b879aeb1c2039683df24d'
Notice: /File[/var/lib/puppet/lib ...
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by jlent
close date 2015-02-27 17:59:26.365680

2 answers

Sort by ยป oldest newest most voted

answered 2015-02-27 13:27:13 -0500

jlent gravatar image

Thanks for the response. I neglected to mention that we ended up seeing this same issue on at least one host that was running an identical version of Puppet as the master.

That being said, we figured out the problem. At some point a while back, one of our three masters had a module installed into /etc/puppet/modules. It wasn't until we told the individual environments to use the basemodulepath that the lack of homogeneity became a problem. Upon reflection it makes sense: A client was seeing the master with the module in /etc/puppet/modules and pulling libraries in (in this case, related to puppetdb). The same client would then hit another master, and think that it needed to purge those libs. If the client hit the same master twice, runs would complete cleanly.

So, the lesson here is that if you have Puppet, use it. Homogeneity in cases like this is very important.

Going to close this out.

edit flag offensive delete link more

answered 2015-02-27 09:43:23 -0500

gh gravatar image


What is the output of the following commands?

puppet config print modulepath

puppet config print environmentpath

puppet config print basemodulepath

Have you restarted the puppet masters after installing new software and tried the clients again?

As an aside, you're asking for trouble by running agents with versions higher than the master. You should immediately upgrade your master or downgrade your agents.

Best regards,


edit flag offensive delete link more

Question Tools



Asked: 2015-02-26 13:18:09 -0500

Seen: 219 times

Last updated: Feb 27 '15