# Fwd: Re: Re: Re: Chef Client .... not doing anything

**URL:** <https://discourse.chef.io/t/fwd-re-re-re-chef-client-not-doing-anything/6029>\
**Category:** Chef Infra (archive)\
**Created:** [December 5, 2014, 7:50pm UTC](https://discourse.chef.io/t/fwd-re-re-re-chef-client-not-doing-anything/6029 "2014-12-05T19:50:57Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lamont\_Granquist](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)\
**Post date:** [December 5, 2014, 7:50pm UTC](https://discourse.chef.io/t/fwd-re-re-re-chef-client-not-doing-anything/6029/1 "2014-12-05T19:50:57Z")

</div>

On 12/5/14, 10:09 AM, Douglas Garstang wrote:

> From [Chef Infra Client Release Notes](https://docs.getchef.com/release_notes.html)
> 
> "Splay and interval values are applied before the chef-client run The  
> --interval and --splay values are applied before the chef-client run  
> when using the chef-client and chef-solo executables."
> 
> I would love to hear the justification for this? Why would someone  
> want to wait 30 minutes for the chef-client to do it's FIRST run?

Because if you run chef-client on the command line as part of a  
bootstrapping process and you have the chef-client cookbook installed  
which manages itself and starts a daemon process to manage chef-client  
then you generally do not want the daemonized chef-client immediately  
launching another chef-client converge while the current one is  
executing. This can cause issues with subsequent bootstrapping code  
since the daemonized asynchronous chef-client process can get into  
fights over things like yum locks. So the first run of chef-client  
should not be with interval or sleep options and will run immediately,  
you should only use the sleeps with daemonized runs, and  
sleeping-first-then-running causes issues with initial asynchronous  
chef-client runs.

---

<div class="post-metadata">

**Author:** ![Douglas\_Garstang](https://avatars.discourse-cdn.com/v4/letter/d/c2a13f/32.png) [@Douglas\_Garstang](https://discourse.chef.io/u/Douglas_Garstang)\
**Post date:** [December 5, 2014, 8:15pm UTC](https://discourse.chef.io/t/fwd-re-re-re-chef-client-not-doing-anything/6029/2 "2014-12-05T20:15:59Z")

</div>

My bootstrapping process doesn't run chef-client on the command line.  
It runs it as a service.

On Fri, Dec 5, 2014 at 11:50 AM, Lamont Granquist [lamont@chef.io](mailto:lamont@chef.io) wrote:

> On 12/5/14, 10:09 AM, Douglas Garstang wrote:
> 
> > From [Chef Infra Client Release Notes](https://docs.getchef.com/release_notes.html)
> > 
> > "Splay and interval values are applied before the chef-client run The  
> > --interval and --splay values are applied before the chef-client run  
> > when using the chef-client and chef-solo executables."
> > 
> > I would love to hear the justification for this? Why would someone  
> > want to wait 30 minutes for the chef-client to do it's FIRST run?
> 
> Because if you run chef-client on the command line as part of a  
> bootstrapping process and you have the chef-client cookbook installed  
> which manages itself and starts a daemon process to manage chef-client  
> then you generally do not want the daemonized chef-client immediately  
> launching another chef-client converge while the current one is  
> executing. This can cause issues with subsequent bootstrapping code  
> since the daemonized asynchronous chef-client process can get into  
> fights over things like yum locks. So the first run of chef-client  
> should not be with interval or sleep options and will run immediately,  
> you should only use the sleeps with daemonized runs, and  
> sleeping-first-then-running causes issues with initial asynchronous  
> chef-client runs.

--  
Regards,

Douglas Garstang  
[http://www.linkedin.com/in/garstang](http://www.linkedin.com/in/garstang)  
Email: [doug.garstang@gmail.com](mailto:doug.garstang@gmail.com)  
Cell: +1-805-340-5627