Luckily this doesn't happen all the time, but I've seen in twice now in
about a year's time on two different Puppet masters. Here's some
background.
I have in a central location a "Grand Master" that serves only the "Remote
Masters" each located in a different data center. On the remote masters is
a copy of the Puppet modules and site.pp as it exists on the Grand Master.
Also on each remote master is an RPM repository containing RPMs developed
in house as well as supporting RPMs for Puppet since nothing in production
can talk over the network to anything outside the data center with
exception of the remote master.
These two sets of data get updated during the normal Puppet agent run on
the remote master. Here is a sanitized version of the Puppet classes doing
the work:
file { '/data/repos':
source =>$repo_src,
backup => false,
source_permissions => use,
purge => true,
recurse => true,
ignore => '*/repodata/*',
force => true,
}
file {'/data/puppet-modules':
source => $src_uri,
backup => false,
purge => true,
source_permissions => use,
recurse => true,
force => true
}
Here's where things get weird. For the second time this has failed and the
transfer between the grand master and the remote master has hung in mid
session. In this last case it wasn't until it started to process the RPM
tree that it hung.
Restarting the master process on the grand master did not help. However,
when I stopped the master process and manually started it in debug mode the
problem went away. This just doesn't make sense to me.
Has anybody else observed this behavior and were you able to resolve it?
--
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/CAArvnv1GM3XT1gsQacWWiDT-ZEvxOZ%2BwKwYDJTrULEn3L7vOcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
