On Tuesday, May 3, 2016 at 9:20:39 AM UTC-5, Karl Murphy wrote: > > Hi John, the logging would suggest that there is no hanging while loading > the LVM facts. All the facts appear to load. Obviously, as we are not using > the most recent puppetlabs-lvm module, we don't have the component relating > to lvm_vg_#*name*_pvs as you highlight above. > > Regarding lvm version and the module version we are using: > > 1) *lvm version* > LVM version: 2.02.111(2)-RHEL6 (2014-09-01) > Library version: 1.02.89-RHEL6 (2014-09-01) > Driver version: 4.27.0 > > 2) *puppetlabs-lvm version* ==> '0.2.0' > > Googling around a little, I found this old thread: https://groups.google.com/forum/#!topic/puppet-users/8GzIjCxfntQ, which relates to a similar execution expired problem, and whose author traces it back to a purported problem with the Ruby gtk2 module interfering with reading from sysfs <https://www.ruby-forum.com/topic/92722>. It doesn't sound so likely that you would be loading gtk2 specifically, but it is entirely plausible that evaluating the LVM facts might involve reading from sysfs, and that Ruby modules other than gtk2 might also cause such trouble. It is also plausible that the problem might disappear after one Puppet run as a result of some key package being updated.
I'm afraid that's not very solid, but it *is* testable. For example, provision a fresh machine as you normally do, up to, but not including the point where you perform the first Puppet run. Run Puppet in --noop mode to try to observe the error without applying any changes. Even in noop mode, the agent should still issue a CSR, perform pluginsync, and load facts. If the error is inconsistent then you may need to make multiple tries, or otherwise try different initial provisioning -- I'm sure you get the idea. If this problem is associated with the clean-from-provisioning state of your machines, then you should not only be able to reproduce it this way, but probably you should also be able to reproduce it multiple times with the same machine, as long as the agent runs in noop mode. If you can in fact establish that, then from there it's probably a question of determining which package update or configuration change makes the problem go away. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/23adabbd-14f8-4b4d-ad37-65ab8d60f5e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
