I see the same issue when changing the runinterval option. I
basically wanted the polling time to change after a successful poll
(after ca clean). I see the "reparsing puppet.conf" in the log file,
but the daemon continues to poll at the original interval.
This is on 0.24.8 on CentOS 5.1, I'm in the process of moving to cron
and running no-daemonize to get around the puppet.conf issue.
2009/7/15 Teyo Tyree <t...@reductivelabs.com>:
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
