On Monday, March 18, 2013 at 10:26 AM, Daniel DeLeo wrote:
On Monday, March 18, 2013 at 9:32 AM, Sascha Bates wrote:
I was looking at this but I found that there was already a discussion and a fix submitted: http://tickets.opscode.com/browse/CHEF-3367What I'm really curious about is why we have two different methods of forking the process: daemon and Chef::Config[:client_fork] true/false. If client_fork is set to false, which it is by default, the daemon takes care of forking and that's when we lose the pid and the client hangs.
"daemon" is for OG Unix process backgrounding: fork, set a new process group, replace stdin/stdout with log file or dev/null, etc."client_fork" is where each chef run forks a new process. It doesn't create a new process group, detach from the terminal or anything like that. The point of client_fork is that a "disposable" process is used for each run, so a cookbook cannot pollute state that is persisted between runs. This prevents memory leaks in cookbooks (or Chef itself, or some interaction between the two) from impacting the system since the process dies and returns its memory at the end of the run.I'll see about getting both of these tickets looked at during today's code review.
Archive powered by MHonArc 2.6.16.