Yup, that was definitely it. Threw something in the hosts file to just dummy out a hostname for the returned IP, and now it's quite speedy.
Thanks, never would have found that left to my own devices. On Aug 17, 2:49 pm, Scott Smith <sc...@ohlol.net> wrote: > Run arp -a > > If it hangs at any point, that is likely the problem. I'm not suggesting > that arp is the problem, rather that you might have entries for IP addresses > that have no PTR. > > See:http://projects.puppetlabs.com/issues/8247 > > -scott > > On Wed, Aug 17, 2011 at 12:40 PM, Dragonfyre13 <dragonfyr...@gmail.com>wrote: > > > > > > > > > Not as far as I can tell. I can honestly say I didn't look that far > > down the chain yet though, except that name resolution is occurring > > quickly and successfully for each of the boxes in play (I did test on > > fqdn, ip, and hostname FYI, so it's not a resolution issue). Note also > > that tcp and udp connections and packets between these servers are in > > the single digit ms range from my tests (although of course ARP > > resolution would be below either of these), and they are sitting > > behind a single switch prior to exiting to the primary lab switches. I > > would anticipate that puppet wouldn't be the only application with > > this issue if it were at the ARP level though, and I'm able to > > communicate between the systems fine via other methods. > > > If you want to direct me to something on how I can confirm, I'm more > > than happy to try. Not entirely sure to check existing PTR entries > > against the ARP cache. > > > On Aug 17, 12:54 pm, Scott Smith <sc...@ohlol.net> wrote: > > > Do you have any arp entries for which there is no PTR? > > > On Aug 17, 2011 10:23 AM, "Dragonfyre13" <dragonfyr...@gmail.com> wrote: > > > > > Hoping you guys might be able to help me out, I'm not sure what's > > > > wrong but puppet agent hangs for over a minute, no resource spikes > > > > (CPU, memory, etc all stay basically the same as without starting > > > > puppet, barely a blip, and I've got more than enough headroom). It's > > > > not a serious issue for continuous usage, but really, really annoying > > > > when testing the manifests I'm starting to create. > > > > > Below is a snippet of the agent's output when run with: > > > > puppet agent --test --noop --debug --trace --verbose --waitforcert 0 > > > > > Master is running as: > > > > puppet master --no-daemonize --debug --trace --logdest --summarize > > > > > Agent log segment: > > > > [snip] > > > > debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/ > > > > puppet] > > > > debug: Finishing transaction 70059796256340 > > > > debug: Using cached certificate for ca > > > > debug: Using cached certificate for ubuntu05.wic.west.com > > > > debug: Finishing transaction 70059798542500 > > > > debug: Loaded state in 0.00 seconds > > > > debug: Using cached certificate for ca > > > > debug: Using cached certificate for ubuntu05.wic.west.com > > > > debug: Using cached certificate_revocation_list for ca > > > > debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw > > > > yaml; using pson > > > > [snip] > > > > debug: Storing state > > > > debug: Stored state in 0.01 seconds > > > > notice: Finished catalog run in 0.16 seconds > > > > Changes: > > > > Events: > > > > Noop: 2 > > > > Total: 2 > > > > Resources: > > > > Total: 12 > > > > Out of sync: 2 > > > > Skipped: 6 > > > > Time: > > > > Filebucket: 0.00 > > > > Package: 0.00 > > > > Exec: 0.00 > > > > Config retrieval: 0.44 > > > > Total: 0.45 > > > > Last run: 1313600473 > > > > debug: Using cached certificate for ca > > > > debug: Using cached certificate for ubuntu05.wic.west.com > > > > debug: Using cached certificate_revocation_list for ca > > > > debug: Value of 'preferred_serialization_format' (pson) is invalid for > > > > report, using default (b64_zlib_yaml) > > > > debug: report supports formats: b64_zlib_yaml marshal raw yaml; using > > > > b64_zlib_yaml > > > > > Master Log: > > > > info: Expiring the node cache of ubuntu05.wic.west.com > > > > info: Not using expired node for ubuntu05.wic.west.com from cache; > > > > expired at Wed Aug 17 13:00:12 -0400 2011 > > > > info: Caching node for ubuntu05.wic.west.com > > > > debug: Exec[pwd]: Adding default for logoutput > > > > debug: Exec[pwd]: Adding default for path > > > > debug: Exec[whoami]: Adding default for logoutput > > > > debug: Exec[whoami]: Adding default for path > > > > notice: Compiled catalog for ubuntu05.wic.west.com in environment > > > > production in 0.04 seconds > > > > > Agent hangs between: > > > > debug: Loaded state in 0.00 seconds > > > > debug: Using cached certificate for ca > > > > > It sits there for over a minute before moving on. I've tried an agent > > > > on a different system from the master, agent on the same system (as > > > > above), they have the exact same behavior. At first I thought it was > > > > the manifest I created (nothing complicated, followed ntp stuff and > > > > adapted it slightly for the most part), but running this with > > > > absolutely no manifests being applied for the node hangs for the same > > > > period of time, in the same place. > > > > > I'm using webrick for the server, but since right now I have a single > > > > client, and that's being fired off manually (not in cron, not a long > > > > running client, etc), using webrick shouldn't be an issue as far as I > > > > know. I setup minimal config files, (defaults only) as I originally > > > > thought maybe the master was delaying things due to not finding the > > > > configs it wanted. It reduced the logs, but didn't speed it up at all. > > > > > I setup everything per the simple recipe, and haven't gone much > > > > further than that. Any info needed should be easy to post, but this is > > > > just currently an annoyance more than anything. Once I have everything > > > > running, I should be fine to have the minute+ delay in with every > > > > sync, but for testing manifests, etc it's really slowing things down. > > > > > -- > > > > 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. > > > -- > > 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. -- 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.
