Client locking


#1

I’m starting new instances, and the chef clients starts on boot from init.
I’m then stopping it (service chef-client stop), and running it manually so
that I can get a better idea of what’s going on. I recently added the
chef-client to the runlist, and ocassionally duing the foreground run, the
client barfs with locking errors (from yum). This would tend to indicate to
me that the client started from the recipe is trying to run while the
client is also running in the foreground.

I thought I had seen in the past where, if the client was actually running
(not just running as a daemon) that running it on the foreground would tell
the client was already running and stop.

Bottom line… does the client have locking? What happens if it’s doing a
foreground run and the daemon kicks off a parallel run?

Doug


#2

Both chef run_lock_timeout and yum_lock_timeout (hehe) are
configurable via client.rb


cheers,

aj

On Wed, Aug 13, 2014 at 11:13 AM, Douglas Garstang
doug.garstang@gmail.com wrote:

I’m starting new instances, and the chef clients starts on boot from init.
I’m then stopping it (service chef-client stop), and running it manually so
that I can get a better idea of what’s going on. I recently added the
chef-client to the runlist, and ocassionally duing the foreground run, the
client barfs with locking errors (from yum). This would tend to indicate to
me that the client started from the recipe is trying to run while the client
is also running in the foreground.

I thought I had seen in the past where, if the client was actually running
(not just running as a daemon) that running it on the foreground would tell
the client was already running and stop.

Bottom line… does the client have locking? What happens if it’s doing a
foreground run and the daemon kicks off a parallel run?

Doug


#3

On 8/12/14, 4:13 PM, Douglas Garstang wrote:

I’m starting new instances, and the chef clients starts on boot from
init. I’m then stopping it (service chef-client stop), and running it
manually so that I can get a better idea of what’s going on. I
recently added the chef-client to the runlist, and ocassionally duing
the foreground run, the client barfs with locking errors (from yum).
This would tend to indicate to me that the client started from the
recipe is trying to run while the client is also running in the
foreground.

I thought I had seen in the past where, if the client was actually
running (not just running as a daemon) that running it on the
foreground would tell the client was already running and stop.

Bottom line… does the client have locking? What happens if it’s
doing a foreground run and the daemon kicks off a parallel run?

Doug

Yeah the client has locks so that two chef-clients won’t run at the same
time (and a different lock to make sure two daemonized CCRs don’t run at
the same time).

I think the chef-client stop will asynchronously tell the daemon you
started to exit which will wait for the current CCR to stop, then the
new CCR should block until that finishes. I think either you’re doing
something to hard interrupt the CCR and its exiting and releasing its
lockfile but orphaning some yum/rpm processes or else you’ve got other
processes going on in the background that are doing rpm/yum things.