On Sat, Jul 11, 2009 at 1:18 AM, Greg <greg.b...@gmail.com> wrote:
>
> Paul,
>
> I've seen similar behaviour, but it shows up for me with the list of
> classes. I have a staging server for testing rolling out new puppet
> configs. Upon getting the new config, puppet seems to use the same
> server until restarting. I don't have a solution yet, but heres what I
> know to add to the conversation.
>
> I tried using:
>
> service { "puppetd":
> ensure => running,
> subscribe => File["/etc/puppet/puppet.conf"]
> }
>
> And that worked... For a while... This has 2 interesting side effects
> for me (on Solaris, at least)
>
> 1. It would stop things mid-run. As soon as a puppet.conf was updated
> it would restart. Mostly that is OK, but if you have schedules,
> sometimes they get triggered without actually doing any work because
> Puppet is shutting down. I suspect this is because it checks an item,
> then receives the shutdown signal and doesn't get to finish the job
> its doing.
>
> 2. *Sometimes* puppet would not shut down correctly. Would get the
> signal, start to shut down then hang. If I ever figure out why or how
> its doing this I will submit a bug report. This happens for us only
> occasionally, and usually SMF kicks in and puts it into maintenance
> state at which point it kills with a -9 and then waits for someone to
> svcadm clear it.
>
> For us, this started happening long after we upgraded from 0.24.7 to
> 0.24.8... We also run our staging server on a different port to the
> production Puppet server to make sure that it doesn't accidentally get
> used.
>
> The only thing I can think of is that maybe the server name gets
> cached somewhere else other than config - and maybe it isn't being
> cleaned out when the config is being re-read... I can understand there
> being a server connection cached for the run, but once its finished it
> should in theory be cleared out...
>
> Greg
>
> On Jul 11, 9:31 am, Paul Lathrop <p...@tertiusfamily.net> wrote:
> > Dear Puppeteers,
> >
> > I'm in desperate need of help. Here's the story:
> >
> > When I boot up new machines, they have a default puppet.conf which
> > causes them to talk to our production puppetmaster at
> > puppet.digg.internal. Some of these machines are destined for our
> > development environment, and there is a custom fact 'digg_environment'
> > that the default config uses to pass out an updated puppet.conf file.
> > For these development machines, this file points server= to
> > puppet.dev.digg.internal, which has a node block for the machine that
> > then has their full configuration.
> >
> > This all seemed to work great until recently, and I'm not sure what
> changed.
> >
> > Now, what happens is that the machine boots with the default
> > puppet.conf. It talks to the production puppetmaster, and downloads
> > the correct puppet.conf which points server= to
> > puppet.dev.digg.internal. In the logs, I see the "Reparsing
> > /etc/puppet/puppet.conf" message. The report ends up getting sent to
> > the development puppetmaster (puppet.dev.digg.internal). However, on
> > subsequent runs, puppetd continues to talk to the production
> > puppetmaster instead of getting it's config from the development
> > puppetmaster! After a manual restart of the daemon, it works as
> > expected. However, manual steps are a big bummer!
> >
> > The only change I can think of here is that we switched to Debian
> > Lenny. Puppet version is 0.24.8. Any help would be appreciated!
> >
> > Thanks,
> > Paul
> >
> The bad news:
We need to track down why exactly the server parameter is getting cached.
Additionally, puppet should not restart in the middle of a transaction
(There is a ticket for 0.25 to make this behavior optional, but currently it
should restart post transaction. Both of these are bugs and should be
reported as such.
The good news:
Paul, one work around for your issue is to do something completely different
at provisioning time. What I do is use a very simple init script to
bootstrap puppetd. Instead of using puppetd to bootstrap itself, just use
the puppet executable and a simple bootstrap module in your init script.
The bootstrap manifest should use the services resource type to
start/restart puppetd and to disable the bootstrap init script and a file
resource to manage puppet.conf. This approach won't address any changes to
puppet.conf after provisioning, but should address your specific issue at
provisioning time.
-teyo
--
Teyo Tyree :: www.reductivelabs.com :: +1.615.275.5066
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
