On Wednesday, March 23, 2016 at 9:43:44 AM UTC-5, Salty Old Cowdawg wrote:

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.
>
>

Are you saying that after working as expected for many cycles on all the 
machines involved, one or more of the remote masters' own catalog runs 
against the central master started failing consistently? Because it's 
unclear to me why restarting a master process would be expected to rescue a 
stalled catalog run of one of the agents associated with it.
 


> Has anybody else observed this behavior and were you able to resolve it?
>
>

I have not observed the behavior you describe, but the most prominent red 
flag (ok, maybe yellow flag) that I see in the resource declarations you 
presented is their reliance on recursive File resources.  These are a 
continual sore spot for Puppet, and they frequently cause problems when 
applied to directory trees that have either large numbers of files or a 
large volume of data, for values of "large" that are somewhat 
environment-dependent.

I cannot be confident that it will solve the problem you observed, but on 
general principles I would recommend that you choose a different mechanism 
for synching those files.  Git and rsync seem to be popular tools for that, 
and both can be driven by Puppet.


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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/065b9c73-f391-47d7-8286-b6e27c7b8918%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to