Yes. it will be wrote in log.On Sep 7, 2012, at 12:37 AM, Paul McCallick <
">
> wrote: Yikes. Will this at least get captured in the logs? One more thing need your attention, exception handler can only handle runtime exception but not compile time exception. If your recipe broke on compile time, the chef-client will stop without running and exception handler.
Thanks everyone, it sounds like handlers are the way to go. well, it really depends on how you manage operations carried out by chef. By running chef as daemon, chef will apply your changes in next time it runs. So longer the interval between 2 converges is, more changes may be made. And more changes you make once, more risk you have. For example, if one recipes failed, all recipes after that will not be run. So you need to figure out which one failed, fix it an run everything again. OMP, running chef-client on demand will be a better solution. Tetsu, can you elaborate on the concerns you've got for running chef-client as a daemon? You can use exception handler to get runtime exception on your recipes. To monitor chef-client process, you can use god, which is a process monitor written in Ruby. btw, running chef-client as a daemon is not good in some case. be careful with that. We’re fairly new to chef and have been manually executing chef runs on one or many nodes. We just made the move to run it as a service via the chef-client cookbook. What’s the quickest way to make sure that we’re getting notified when there are problems during a chef run? What’s the best way?
|