Re: [Puppet Users] Re: PuppetDB 1.6.3 final now available
Sorry, you can disregard. It turns out the database was screwed up before the upgrade. This was just on my failover server so a purge and reinitialization took care of it. On Tuesday, April 22, 2014 6:40:45 PM UTC-4, Ken Barber wrote: > > We didn't actually provide any database schema migration for > 1.6.2->1.6.3. This in fact looks like its trying to migrate from > scratch as if you have no tables loaded, this is done by looking at > the schema_migrations table to work out what needs to be updated. > > So I guess the question is, what does your schema_migrations table > look like? Here is an example of how to get a hold of that info: > https://gist.github.com/kbarber/11196805 > > ken. > > > On Tue, Apr 22, 2014 at 11:10 PM, David Mesler > > > wrote: > > I'm having an issue updating from 1.6.2. > > > > 2014-04-22 17:00:33,043 INFO [main] [cli.services] PuppetDB version > 1.6.3 > > 2014-04-22 17:00:33,124 ERROR [main] [scf.migrate] Caught SQLException > > during migration > > java.sql.BatchUpdateException: Batch entry 0 CREATE TABLE certnames > (name > > TEXT PRIMARY KEY) was aborted. Call getNextException to see the cause. > > at > > > org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2746) > > > > at > > > org.postgresql.core.v3.QueryExecutorImpl$1.handleError(QueryExecutorImpl.java:457) > > > > at > > > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1887) > > > > at > > > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:405) > > > at > > > org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2893) > > > > at > > com.jolbox.bonecp.StatementHandle.executeBatch(StatementHandle.java:469) > > at clojure.java.jdbc$do_commands$fn__2182.invoke(jdbc.clj:188) > > at > > clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:223) > > at clojure.java.jdbc$do_commands.doInvoke(jdbc.clj:187) > > at clojure.lang.RestFn.invoke(RestFn.java:408) > > at clojure.java.jdbc$create_table.doInvoke(jdbc.clj:236) > > at clojure.lang.RestFn.invoke(RestFn.java:423) > > at > > > com.puppetlabs.puppetdb.scf.migrate$initialize_store.invoke(migrate.clj:95) > > at > > > com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_$fn__12703$fn__12716.invoke(migrate.clj:740) > > > > at > > > com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_$fn__12703.invoke(migrate.clj:739) > > > > at > > clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:204) > > at > > > com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_.invoke(migrate.clj:736) > > at > > > com.puppetlabs.puppetdb.cli.services$_main$fn__12813.invoke(services.clj:274) > > > at > > > clojure.java.jdbc.internal$with_connection_STAR_.invoke(internal.clj:186) > > at > > com.puppetlabs.puppetdb.cli.services$_main.doInvoke(services.clj:272) > > at clojure.lang.RestFn.invoke(RestFn.java:421) > > at clojure.lang.Var.invoke(Var.java:419) > > at clojure.lang.AFn.applyToHelper(AFn.java:163) > > at clojure.lang.Var.applyTo(Var.java:532) > > at clojure.core$apply.invoke(core.clj:617) > > at com.puppetlabs.puppetdb.core$run_command.invoke(core.clj:87) > > at com.puppetlabs.puppetdb.core$_main.doInvoke(core.clj:95) > > at clojure.lang.RestFn.applyTo(RestFn.java:137) > > at com.puppetlabs.puppetdb.core.main(Unknown Source) > > 2014-04-22 17:00:33,125 ERROR [main] [scf.migrate] Unravelled exception > > org.postgresql.util.PSQLException: ERROR: relation "certnames" already > > exists > > at > > > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157) > > > > at > > > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886) > > > > at > > > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:405) > > > at > > > org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2893) > > > > at > > com.jolbox.bonecp.StatementHandle.executeBatch(StatementHandle.java:469) > > at clojure.java.jdbc$do_commands$fn
[Puppet Users] Re: PuppetDB 1.6.3 final now available
I'm having an issue updating from 1.6.2. 2014-04-22 17:00:33,043 INFO [main] [cli.services] PuppetDB version 1.6.3 2014-04-22 17:00:33,124 ERROR [main] [scf.migrate] Caught SQLException during migration java.sql.BatchUpdateException: Batch entry 0 CREATE TABLE certnames (name TEXT PRIMARY KEY) was aborted. Call getNextException to see the cause. at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2746) at org.postgresql.core.v3.QueryExecutorImpl$1.handleError(QueryExecutorImpl.java:457) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1887) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:405) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2893) at com.jolbox.bonecp.StatementHandle.executeBatch(StatementHandle.java:469) at clojure.java.jdbc$do_commands$fn__2182.invoke(jdbc.clj:188) at clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:223) at clojure.java.jdbc$do_commands.doInvoke(jdbc.clj:187) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.java.jdbc$create_table.doInvoke(jdbc.clj:236) at clojure.lang.RestFn.invoke(RestFn.java:423) at com.puppetlabs.puppetdb.scf.migrate$initialize_store.invoke(migrate.clj:95) at com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_$fn__12703$fn__12716.invoke(migrate.clj:740) at com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_$fn__12703.invoke(migrate.clj:739) at clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:204) at com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_.invoke(migrate.clj:736) at com.puppetlabs.puppetdb.cli.services$_main$fn__12813.invoke(services.clj:274) at clojure.java.jdbc.internal$with_connection_STAR_.invoke(internal.clj:186) at com.puppetlabs.puppetdb.cli.services$_main.doInvoke(services.clj:272) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:419) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:532) at clojure.core$apply.invoke(core.clj:617) at com.puppetlabs.puppetdb.core$run_command.invoke(core.clj:87) at com.puppetlabs.puppetdb.core$_main.doInvoke(core.clj:95) at clojure.lang.RestFn.applyTo(RestFn.java:137) at com.puppetlabs.puppetdb.core.main(Unknown Source) 2014-04-22 17:00:33,125 ERROR [main] [scf.migrate] Unravelled exception org.postgresql.util.PSQLException: ERROR: relation "certnames" already exists at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:405) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2893) at com.jolbox.bonecp.StatementHandle.executeBatch(StatementHandle.java:469) at clojure.java.jdbc$do_commands$fn__2182.invoke(jdbc.clj:188) at clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:223) at clojure.java.jdbc$do_commands.doInvoke(jdbc.clj:187) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.java.jdbc$create_table.doInvoke(jdbc.clj:236) at clojure.lang.RestFn.invoke(RestFn.java:423) at com.puppetlabs.puppetdb.scf.migrate$initialize_store.invoke(migrate.clj:95) at com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_$fn__12703$fn__12716.invoke(migrate.clj:740) at com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_$fn__12703.invoke(migrate.clj:739) at clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:204) at com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_.invoke(migrate.clj:736) at com.puppetlabs.puppetdb.cli.services$_main$fn__12813.invoke(services.clj:274) at clojure.java.jdbc.internal$with_connection_STAR_.invoke(internal.clj:186) at com.puppetlabs.puppetdb.cli.services$_main.doInvoke(services.clj:272) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:419) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:532) at clojure.core$apply.invoke(core.clj:617) at com.puppetlabs.puppetdb.core$run_command.invoke(core.clj:87) at com.puppetlabs.puppetdb.core$_main.doInvoke(core.clj:95) at clojure.lang.RestFn.applyTo(RestFn.java:137) at com.puppetlabs.puppetdb.core.main(Unknown Source) 2014-04-22 17:00:33,128 INFO [Thread-4] [cli.services] Shutdown request received; puppetdb exiting. -- You received this message because you are subscribed to the Google G
[Puppet Users] Re: Announce: Puppet 3.5.0-rc2 Available.
Currently I use the common import "nodes/*" method. With that I've always had to restart the puppet master processes in order to process new node files. Will that still be necessary with the new manifest directory behavior? -- 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/9b64ab3d-a3f4-440f-863d-89ee45c94935%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Help with scaling puppetdb/postgres
Well I found the cause of my 1% duplication rate. I was using the recommendation from this page (http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML) to generate a facts.yaml file for mcollective. I got rid of that and my catalog duplication went up to 73%. I'm not sure what else is changing, my catalogs are huge and I don't know how to diff unsorted json files. I also moved to a server with a 10 disk RAID10 and performance is better. I'm still having trouble tuning autovacuum. Either vacuums never finish because they're constantly delayed, or they eat up all the IO and things grind to a halt. And even when IO seems low there are still times where the puppetdb queue swells to over 1000 before draining. On Tuesday, October 29, 2013 2:32:54 PM UTC-4, Ryan Senior wrote: > > 1.5% catalog duplication is really low and from a PuppetDB perspective, > means a lot more database I/O. I think that probably explains the problems > you are seeing. A more typical duplication percentage would be something > over 90%. > > The next step here is figuring out why the duplication percentage is so > low. There's a ticket I'm working on now [1] to help in debugging these > kinds of issues with catalogs, but it's not done yet. One option you have > now is to query for the current catalog of a node after a few subsequent > catalog updates. You can do this using curl and the catalogs API [2]. > That API call will give you a JSON representation of the catalog data from > PuppetDB for that node. You can then compare the JSON files and see if you > maybe have a resource that is changing with each run. If you need help > getting that information or want some more help troubleshooting the output, > head over to #puppet on IRC [3] and one of the PuppetDB folks can help you > out. > > > 1 - https://projects.puppetlabs.com/issues/22977 > 2 - https://docs.puppetlabs.com/puppetdb/1.5/api/query/v3/catalogs.html > 3 - http://projects.puppetlabs.com/projects/1/wiki/Irc_Channel > > > On Tue, Oct 29, 2013 at 11:50 AM, David Mesler > > > wrote: > >> Resource duplication is 98.7%, catalog duplication is 1.5%. >> >> On Tuesday, October 29, 2013 9:06:37 AM UTC-4, Ken Barber wrote: >>> >>> Hmm. >>> >>> > I reconfigured postgres based on the recommendations from pgtune and >>> your >>> > document. I still had a lot of agent timeouts and eventually after >>> running >>> > overnight the command queue on the puppetdb server was over 4000. >>> Maybe I >>> > need a box with traditional RAID and a lot of spindles instead of the >>> SSD. >>> > Or maybe I need a cluster of postgres servers (if that's possible), I >>> don't >>> > know. The puppetdb docs said a laptop with a consumer grade SSD was >>> enough >>> > for 5000 virtual nodes so I was optimistic this would be a simple >>> setup. Oh >>> > well. >>> >>> So the reality is, you are effectively running 5200 nodes in >>> comparison with the vague statement in the docs. This is because you >>> are running every 15 minutes, whereas the statement presumes running >>> every hour. >>> >>> Can we get a look at your dashboard? In particular your catalog and >>> resource duplication rate? >>> >>> ken. >>> >> -- >> 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...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/46312de5-62fb-4844-9ab6-a93a01abfe24%40googlegroups.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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/c92a6d01-bed2-462a-a536-69f0dae33fc0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Help with scaling puppetdb/postgres
Resource duplication is 98.7%, catalog duplication is 1.5%. On Tuesday, October 29, 2013 9:06:37 AM UTC-4, Ken Barber wrote: > > Hmm. > > > I reconfigured postgres based on the recommendations from pgtune and > your > > document. I still had a lot of agent timeouts and eventually after > running > > overnight the command queue on the puppetdb server was over 4000. Maybe > I > > need a box with traditional RAID and a lot of spindles instead of the > SSD. > > Or maybe I need a cluster of postgres servers (if that's possible), I > don't > > know. The puppetdb docs said a laptop with a consumer grade SSD was > enough > > for 5000 virtual nodes so I was optimistic this would be a simple setup. > Oh > > well. > > So the reality is, you are effectively running 5200 nodes in > comparison with the vague statement in the docs. This is because you > are running every 15 minutes, whereas the statement presumes running > every hour. > > Can we get a look at your dashboard? In particular your catalog and > resource duplication rate? > > ken. > -- 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/46312de5-62fb-4844-9ab6-a93a01abfe24%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Help with scaling puppetdb/postgres
I reconfigured postgres based on the recommendations from pgtune and your document. I still had a lot of agent timeouts and eventually after running overnight the command queue on the puppetdb server was over 4000. Maybe I need a box with traditional RAID and a lot of spindles instead of the SSD. Or maybe I need a cluster of postgres servers (if that's possible), I don't know. The puppetdb docs said a laptop with a consumer grade SSD was enough for 5000 virtual nodes so I was optimistic this would be a simple setup. Oh well. On Thursday, October 24, 2013 1:02:55 PM UTC-4, Ken Barber wrote: > > pgtune is probably a good place to start: > https://github.com/gregs1104/pgtune ... available as an rpm/deb on the > more popular distros I believe. > > Also, this is probably very premature, but I have a draft doc with > notes for how to tune your DB for PuppetDB: > > > https://docs.google.com/document/d/1hpFbh2q0WmxAvwfWRlurdaEF70fLc6oZtdktsCq2UFU/edit?usp=sharing > > > Use at your own risk, as it hasn't been completely vetted. Happy to > get any feedback on this, as I plan on making this part of our > endorsed documentation. > > Also ... there is an index that lately has been causing people > problems 'idx_catalog_resources_tags_gin'. You might want to try > dropping it to see if it improves performances (thanks to Erik Dalen > and his colleagues for that one): > > DROP INDEX idx_catalog_resources_tags_gin; > > It is easily restored if it doesn't help ... but may take some time to > build: > > CREATE INDEX idx_catalog_resources_tags_gin > ON catalog_resources > USING gin > (tags COLLATE pg_catalog."default"); > > ken. > > On Thu, Oct 24, 2013 at 4:55 PM, David Mesler > > > wrote: > > Hello, I'm currently trying to deploy puppetdb to my environment but I'm > > having difficulties and am unsure on how to proceed. > > I have 1300+ nodes checking in at 15 minute intervals (3.7 million > resources > > in the population). The load is spread across 6 puppet masters. I > > requisitioned what I thought would be a powerful enough machine for the > > puppetdb/postgres server. A machine with 128GB of RAM, 16 physical cpu > > cores, and a 500GB ssd for the database. I can point one or two of my > puppet > > masters at puppetdb with reasonable enough performance, but anymore and > > commands start stacking up in the puppetdb command queue and agents > start > > timing out. (Actually, even with just one puppet master using puppetdb I > > still have occasional agent timeouts.) Is one postgres server not going > to > > cut it? Do I need to look into clustering? I'm sure some of you must run > > puppetdb in larger environments than this, any tips? > > > > -- > > 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...@googlegroups.com . > > To post to this group, send email to > > puppet...@googlegroups.com. > > > Visit this group at http://groups.google.com/group/puppet-users. > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/32aeae93-6636-4f30-83a4-69036374b8fe%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Help with scaling puppetdb/postgres
Hello, I'm currently trying to deploy puppetdb to my environment but I'm having difficulties and am unsure on how to proceed. I have 1300+ nodes checking in at 15 minute intervals (3.7 million resources in the population). The load is spread across 6 puppet masters. I requisitioned what I thought would be a powerful enough machine for the puppetdb/postgres server. A machine with 128GB of RAM, 16 physical cpu cores, and a 500GB ssd for the database. I can point one or two of my puppet masters at puppetdb with reasonable enough performance, but anymore and commands start stacking up in the puppetdb command queue and agents start timing out. (Actually, even with just one puppet master using puppetdb I still have occasional agent timeouts.) Is one postgres server not going to cut it? Do I need to look into clustering? I'm sure some of you must run puppetdb in larger environments than this, any tips? -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet agent periodically not running after 3.0 upgrade
My ceil theory didn't pan out. But here's a working fix: --- puppet-3.0.1.orig/lib/puppet/daemon.rb 2012-10-20 00:57:50.0 -0400 +++ puppet-3.0.1/lib/puppet/daemon.rb 2012-12-21 08:27:17.0 -0500 @@ -164,6 +164,8 @@ next_reparse = 0 reparse_interval = Puppet[:filetimeout] +next_event = 0 + loop do now = Time.now.to_i @@ -172,7 +174,9 @@ # the math messes up or something; it should be inexpensive enough to # wake once an hour, then go back to sleep after doing nothing, if # someone only wants listen mode. - next_event = now + 60 * 60 + if now >= next_event || next_event == 0 +next_event = now + 60 * 60 + end # Handle reparsing of configuration files, if desired and required. # `reparse` will just check if the action is required, and would be @@ -194,7 +198,7 @@ # next time it is scheduled to run, just in case. In the event that # we made no change the result will be a zero second adjustment. new_run_interval= [Puppet[:runinterval], 0].max -next_agent_run += agent_run_interval - new_run_interval +next_agent_run += new_run_interval - agent_run_interval agent_run_interval = new_run_interval end On Thursday, December 20, 2012 4:09:09 PM UTC-5, David Mesler wrote: > > I’ve added some debugging messages to run_event_loop and figured out what > was going on. I’m going to reference line numbers in > https://github.com/puppetlabs/puppet/blob/master/lib/puppet/daemon.rb to > make it easier on me to explain. I found that occasionally the “if” > statement on line 180 was failing because the value of “now” was one second > behind “next_reparse”. I believe this is because line 168 uses “to_i” when > it should use “ceil”. I’m deploying a patched version of puppet with this > change to my servers now. > > But I think a bigger issue is line 175 where next_event is set to the > current time plus one hour. That’s a pretty arbitrary and unpleasant value. > Why not set next_event to the lower vale of :runinterval or :filetimeout? > The way it is now, if line 180 fails, you’re stuck with an hour long wait > even though your :runinterval may be far less. > > Also, line 197 is backwards. It should be “next_agent_
[Puppet Users] Re: puppet agent periodically not running after 3.0 upgrade
I’ve added some debugging messages to run_event_loop and figured out what
was going on. I’m going to reference line numbers in
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/daemon.rb to
make it easier on me to explain. I found that occasionally the “if”
statement on line 180 was failing because the value of “now” was one second
behind “next_reparse”. I believe this is because line 168 uses “to_i” when
it should use “ceil”. I’m deploying a patched version of puppet with this
change to my servers now.
But I think a bigger issue is line 175 where next_event is set to the
current time plus one hour. That’s a pretty arbitrary and unpleasant value.
Why not set next_event to the lower vale of :runinterval or :filetimeout?
The way it is now, if line 180 fails, you’re stuck with an hour long wait
even though your :runinterval may be far less.
Also, line 197 is backwards. It should be “next_agent_run +=
new_run_interval – agent_run_interval”.
On Tuesday, December 18, 2012 7:00:42 PM UTC-5, David Mesler wrote:
>
> I've noticed when I strace a puppet agent that has failed to run after its
> 900 second runinterval, it's blocking on a really long select call. Like:
> select(1, [], [], [], {1032, 35}
>
> When that's done it finally re-reads pupet.conf and stars a catalog run. I
> have no idea where that long select call comes from.
>
> On Friday, December 14, 2012 3:15:25 PM UTC-5, David Mesler wrote:
>>
>> I've recently upgraded from 2.6.9 to 3.0.1 and have noticed an oddity.
>> Our puppet agents are configured with a runinterval of 900 and a splaylimit
>> of 450. Since upgrading I've noticed that once or twice a day our puppet
>> agents simply won't run for about an hour or so. Has anyone else
>> experienced anything like this?
>>
>> --david
>>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/dBF1U0izljQJ.
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.
[Puppet Users] Re: puppet agent periodically not running after 3.0 upgrade
I've noticed when I strace a puppet agent that has failed to run after its
900 second runinterval, it's blocking on a really long select call. Like:
select(1, [], [], [], {1032, 35}
When that's done it finally re-reads pupet.conf and stars a catalog run. I
have no idea where that long select call comes from.
On Friday, December 14, 2012 3:15:25 PM UTC-5, David Mesler wrote:
>
> I've recently upgraded from 2.6.9 to 3.0.1 and have noticed an oddity. Our
> puppet agents are configured with a runinterval of 900 and a splaylimit of
> 450. Since upgrading I've noticed that once or twice a day our puppet
> agents simply won't run for about an hour or so. Has anyone else
> experienced anything like this?
>
> --david
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/1JiAUgNJFmQJ.
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.
[Puppet Users] Re: Puppet Agent 3.0.1 intermitently doesn't wake up
Do they ever wake up on their own? I just posted about my issue where every once in a while my agents will sleep for an hour even though they're configured to run every 15 (+ 7.5 splay) minutes. --david On Wednesday, December 12, 2012 5:50:00 PM UTC-5, MasterPO wrote: > > I have 39 RHEL nodes running the puppet agent and intermitently from 1 to > 3 nodes will go unresponsive and require intervention to become active > again. > > I collected the following for one such instance from this morning: > > Hung Puppet agent information: > > [root@anmvwms3 ~]# rpm -qa | grep puppet > puppet-3.0.1-1.el5 > > > [root@anmvwms3 ~]# ps -ef | grep puppet > root 12421 1 0 Dec10 ?00:03:02 /usr/bin/ruby > /usr/bin/puppet agent --server=puppet --logdest=/var/log/puppet/puppet.log > > [root@anmvwms3 ~]# ps -eo pid,ppid,state,comm,time,pri,size,wchan | grep > puppet > 12421 1 S puppet 00:03:02 21 43028 - > > [root@anmvwms3 ~]# ps -elf | grep 12421 > 5 S root 12421 1 0 78 0 - 12877 - Dec10 ?00:03:02 > /usr/bin/ruby /usr/bin/puppet agent --server=puppet > --logdest=/var/log/puppet/puppet.log > > > [root@anmvwms3 ~]# cat /proc/12421/status > Name: puppet > State: S (sleeping) > SleepAVG: 78% > Tgid: 12421 > Pid:12421 > PPid: 1 > TracerPid: 0 > Uid:0 0 0 0 > Gid:0 0 0 0 > FDSize: 32 > Groups: 0 1 2 3 4 6 10 > VmPeak:52620 kB > VmSize:51508 kB > VmLck: 0 kB > VmHWM: 36772 kB > VmRSS: 36012 kB > VmData:42748 kB > VmStk: 280 kB > VmExe: 4 kB > VmLib: 8104 kB > VmPTE: 116 kB > StaBrk: 08cb6000 kB > Brk:0a404000 kB > StaStk: bfc8b270 kB > Threads:1 > SigQ: 0/81920 > SigPnd: > ShdPnd: > SigBlk: > SigIgn: > SigCgt: 000182007e47 > CapInh: > CapPrm: feff > CapEff: feff > Cpus_allowed: 0001 > Mems_allowed: 1 > > > Right now, I just restart puppet on the node to get it to resume > functioning. > > Is this a known issue? > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/-xCxvqNZnVMJ. 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.
[Puppet Users] puppet agent periodically not running after 3.0 upgrade
I've recently upgraded from 2.6.9 to 3.0.1 and have noticed an oddity. Our puppet agents are configured with a runinterval of 900 and a splaylimit of 450. Since upgrading I've noticed that once or twice a day our puppet agents simply won't run for about an hour or so. Has anyone else experienced anything like this? --david -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/VvlxFFuXDYgJ. 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.
[Puppet Users] Re: Puppetlabs firewall module
Julia, did you ever figure this out? I'm running into this issue as well.
--david
On Tuesday, May 22, 2012 5:28:05 AM UTC-4, Julia Smith wrote:
>
> I'm trying to use the firewall resource and it works fine for me for
> iptables.
>
> However, I'm not sure how I purge ip6tables?
>
> doing...
>
> resources { "firewall":
> purge => true
> }
>
> only purges iptables.
>
> Currently I have 2 execs for persistence, 1 for iptables and 1 for
> ip6tables depending on which I'm using but my ip6tables don't purge. I
> would have expected them to purge with the code above.
>
> The test examples which come with the module do not have any purge for
> ip6tables.
>
> Any help would be greatly appreciated.
>
> --
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for
> the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/0GkFFf_MTbgJ.
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.
