On Thursday, December 13, 2012 8:54:52 AM UTC-8, Roman Shaposhnik wrote:
>
> On Tue, Dec 11, 2012 at 11:08 AM, Andy Parker
> <an...@puppetlabs.com<javascript:>>
> wrote:
> > That stacktrace is it trying to execute the start command for some
> service
> > and failing. It should be providing a message like "Could not #{type}
> > #{@resource.ref}: #{detail}". Do you get anything like at in the logs?
>
> Yes I do. In fact, let me do a couple more runs on a 100% clean VMs
> so that we can be certain that there's no interference from anything else.
>
> > Is your catalog maybe installing a new puppet package? That looks like
> the
> > puppet process is being sent the HUP signal.
>
> Nope. Nothing like that. And given that these are EC2 VMs I control 100%
> I doubt there's something else going on. But, as I said -- I'll do a
> couple
> more runs today to make 100% sure.
>
> Thanks for all your help so far!
>
> Thanks,
> Roman.
Exec commands are executed within a Timeout::timeout block. If the command
times out, a Timeout::Error will be raised. In ruby 1.8 this is not a
StandardError, so `rescue => exception` will not catch it, and this is what
happens in the resource_harness.
Another place this can happen is when using file resources with remote
sources, e.g. puppet:///modules/..., since ruby's HTTP code will raise
Timeout::Error on a read timeout.
On ruby 1.9, Timeout::Error is a StandardError, so this problem shouldn't
occur there.
I've updated Dominic's ticket http://projects.puppetlabs.com/issues/17887
with this info.
Josh
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-dev/-/Hce3dlZahKQJ.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
