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