# Life cycle of a chef run

**URL:** <https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305>\
**Category:** Chef Infra (archive)\
**Created:** [October 21, 2009, 9:56pm UTC](https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305 "2009-10-21T21:56:00Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tim\_Uckun](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_uckun/32/751_2.png) [@Tim\_Uckun](https://discourse.chef.io/u/Tim_Uckun)\
**Post date:** [October 21, 2009, 9:56pm UTC](https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305/1 "2009-10-21T21:56:00Z")

</div>

Is there a way to wrap some code around the chef run?

I have two specific goals.

1. Catch exceptions and email them to me.
2. Send some data to my monitoring service after the run (if nothing  
else just the fact that the run took place and went OK but I would  
like to include other data from ohai).

---

<div class="post-metadata">

**Author:** ![Nick\_Ohanian](https://avatars.discourse-cdn.com/v4/letter/n/5daacb/32.png) [@Nick\_Ohanian](https://discourse.chef.io/u/Nick_Ohanian)\
**Post date:** [October 22, 2009, 4:27pm UTC](https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305/2 "2009-10-22T16:27:13Z")

</div>

I second this. I had the same need, and I ended up rolling my own scripts to do this. Otherwise there is no visibility into what's "really" going on in the deployment. However, while this is certainly an important part of "managing your servers", it might be outside of the scope of Chef's goals. Chef is good at "configuring your servers", but is it the intent of Chef to (eventually) provide support for "monitoring your servers"?

-Nick

Tim Uckun wrote:

> Is there a way to wrap some code around the chef run?
> 
> I have two specific goals.
> 
> 1. Catch exceptions and email them to me.
> 2. Send some data to my monitoring service after the run (if nothing  
> else just the fact that the run took place and went OK but I would  
> like to include other data from ohai).

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [October 22, 2009, 4:35pm UTC](https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305/3 "2009-10-22T16:35:50Z")

</div>

On Wed, Oct 21, 2009 at 2:56 PM, Tim Uckun [timuckun@gmail.com](mailto:timuckun@gmail.com) wrote:

> Is there a way to wrap some code around the chef run?

Not yet - we have an open Feature Proposal that has some examples of  
how you can get this functionality today, though:

[http://wiki.opscode.com/display/chef/After+hooks](http://wiki.opscode.com/display/chef/After+hooks)

> I have two specific goals.
> 
> 1. Catch exceptions and email them to me.
> 
> 2. Send some data to my monitoring service after the run (if nothing  
> else just the fact that the run took place and went OK but I would  
> like to include other data from ohai).

In both these cases, you'll want to have a recipe that is at the tail  
end of your run. Have it walk the collection (like in the example in  
the After+Hooks) and go nuts. Stick it in a ruby block and inspect  
whether each resource is "updated" to get end-of-run information about  
what happened.

Improving this kind of reporting is definitely on them map.

Adam

--  
Opscode, Inc.  
Adam Jacob, CTO  
T: (206) 508-7449 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [October 22, 2009, 5:14pm UTC](https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305/4 "2009-10-22T17:14:36Z")

</div>

Tim,One (really hacky, some might even say kludgy) way to accomplish what  
you want, at least for reporting of failed runs via email, would be to  
include a Ruby at\_exit hook in a recipe. Note that this is only effective  
if you run the client via cron or some mechanism where the chef-client  
program exits--so anything using the interval (-i) option won't work with  
this hack. Here's some code that demonstrates the various behaviors you can  
see with at\_exit

at\_exit do

p $!.inspect

end

> def raise\_error

raise "an uncaught error"

end

> def let\_script\_reach\_eof

# don't need to do anything

end

> def raise\_and\_rescue

begin

```
raise "an error that will be rescued"

```

rescue =\> e

```
# don't need to do anything

```

end

end

> def exit\_with\_exit

exit 42

end

> 

In the code above, $! is the last "unrescued" error raised. I didn't have a  
chance to see what the results are when using this in a chef run, so you'll  
need to do additional research on your own, but from what I can tell you'll  
have these cases:

- for a successful run, you'll have $!.kind\_of?(SystemExit) #=\> true and  
$!.success? #=\> true
- Chef might kill itself due to a configuration problem or something, in  
this case you'll probably see $!.kind\_of?(SystemExit) #=\> true and  
$!.success #=\> false
- for a run that dies due to an error being raised in a recipe, you should  
that error in $!, i.e., $!.kind\_of?(SystemExit) #=\> false

Hope this helps,  
Daniel DeLeo

On Thu, Oct 22, 2009 at 10:27 AM, Nick Ohanian [nick@geodelic.com](mailto:nick@geodelic.com) wrote:

> I second this. I had the same need, and I ended up rolling my own scripts  
> to do this. Otherwise there is no visibility into what's "really" going on  
> in the deployment. However, while this is certainly an important part of  
> "managing your servers", it might be outside of the scope of Chef's goals.  
> Chef is good at "configuring your servers", but is it the intent of Chef to  
> (eventually) provide support for "monitoring your servers"?
> 
> -Nick
> 
> Tim Uckun wrote:
> 
> > Is there a way to wrap some code around the chef run?
> > 
> > I have two specific goals.
> > 
> > 1. Catch exceptions and email them to me.
> > 2. Send some data to my monitoring service after the run (if nothing  
> > else just the fact that the run took place and went OK but I would  
> > like to include other data from ohai).

---

<div class="post-metadata">

**Author:** ![Tim\_Uckun](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_uckun/32/751_2.png) [@Tim\_Uckun](https://discourse.chef.io/u/Tim_Uckun)\
**Post date:** [October 22, 2009, 11:02pm UTC](https://discourse.chef.io/t/life-cycle-of-a-chef-run/1305/5 "2009-10-22T23:02:14Z")

</div>

On Fri, Oct 23, 2009 at 6:14 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> Tim,  
> One (really hacky, some might even say kludgy) way to accomplish what you  
> want, at least for reporting of failed runs via email, would be to include a  
> Ruby at\_exit hook in a recipe. Note that this is only effective if you run  
> the client via cron or some mechanism where the chef-client program  
> exits--so anything using the interval (-i) option won't work with this hack.  
> Here's some code that demonstrates the various behaviors you can see with  
> at\_exit
> 
> >

Thanks. That's an approach I might try.

I use zabbix for monitoring so I could also send some data to the  
monitoring server from those hooks too I suppose.

In any case it might be enough (for me) to know that something went  
wrong even if it means I have to log into the server and investigate  
further.