On Mon, Aug 08, 2016 at 05:40:24AM -0700, Bret Wortman wrote: > We've been using cron to manage our puppet agents for the past few years > but have discovered some issues where it's running under a different > environment and is having trouble completing when run in cron, but it > works fine as a daemon or from the command line. So I'm preparing to > switch over.
This sounds like an xy problem. Your underlying issue is that the agent sometimes runs under a different environment than desired and you'd like this to stop. Over here we've had agents (3 and 4) running from cron with the following: usecacheonfailure = false environment = (whatever that is) I presume that if we used the cache on failure then if the agent did not retrieve a catalog after an environment change in the ENC then it would perform the agent run with a catalog from an undesired environment. Do you set an environment in your External Node Classifier? If not, and you don't specify the environment in puppet.conf then you will start in the 'production' environment which may not be what you want. Have you been able to narrow down and reproduce the conditions under which your agent runs happen in an undesired environment? You could have a different issue, albeit that I never had your issue in 3.8.6 with multiple environments. NB, xy problem: http://www.perlmonks.org/?node=XY+Problem > Unfortunately, the following doesn't work for my 3.8.6 agents on Centos 6 > systems even though it works fine for 4.3 agents: > > service { "puppet": > ensure => running, > enable => true, > hasstatus => true, > hasrestart => true, > } > > What we see on some agents is that puppet will restart the service each > and every time it runs, which gives us lots of false "changes". Off hand this sounds like the service checker can't find the pid file. If it happens some measurable times per day in your place I would crank up the debug logging and see what's going on. On the other hand, if it works in 4.3, why not upgrade the remaining 3.x agents and call it a day? We've had fewer issues in 4 than we had in 3. > # service puppet status > puppet dead but pid file exists > # ps aux | grep puppet | grep agent > root 9879 0.0 0.0 134404 43516 ? Ss 12:22 0:00 > /usr/bin/ruby/usr/bin/puppet agent > > Has anyone else seen this or know of a workaround? I've tried various ways > of providing a "status => " command but haven't found anything that works > yet. > > -- > 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 [1]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [2]https://groups.google.com/d/msgid/puppet-users/5ae7de27-705f-4856-aa07-68449af7385a%40googlegroups.com. > For more options, visit [3]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:puppet-users+unsubscr...@googlegroups.com > 2. > https://groups.google.com/d/msgid/puppet-users/5ae7de27-705f-4856-aa07-68449af7385a%40googlegroups.com?utm_medium=email&utm_source=footer > 3. https://groups.google.com/d/optout -- 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/20160808141314.GA1149%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
