Puppet users - Aug 2011 - Puppet agent hangs for over a minute, no info in --summarize

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Do you have any arp entries for which there is no PTR?
On Aug 17, 2011 10:23 AM, "Dragonfyre13"
<dragonfyre13@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
<dragonfyre13@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.