Client locking

Douglas_Garstang · August 12, 2014, 11:13pm

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

fujin · August 12, 2014, 11:23pm

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

github.com

chef/chef/blob/main/lib/chef/config.rb#L573-L576


      
          #
          # Author:: Adam Jacob (<adam@chef.io>)
          # Author:: Christopher Brown (<cb@chef.io>)
          # Author:: AJ Christensen (<aj@chef.io>)
          # Author:: Mark Mzyk (<mmzyk@chef.io>)
          # Author:: Kyle Goodwin (<kgoodwin@primerevenue.com>)
          # Copyright:: Copyright (c) Chef Software Inc.
          # License:: Apache License, Version 2.0
          #
          # Licensed under the Apache License, Version 2.0 (the "License");
          # you may not use this file except in compliance with the License.
          # You may obtain a copy of the License at
          #
          #     http://www.apache.org/licenses/LICENSE-2.0
          #
          # Unless required by applicable law or agreed to in writing, software
          # distributed under the License is distributed on an "AS IS" BASIS,
          # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
          # See the License for the specific language governing permissions and
          # limitations under the License.

This file has been truncated. show original

github.com

chef/chef/blob/main/lib/chef/config.rb#L334


      
          #
          # Author:: Adam Jacob (<adam@chef.io>)
          # Author:: Christopher Brown (<cb@chef.io>)
          # Author:: AJ Christensen (<aj@chef.io>)
          # Author:: Mark Mzyk (<mmzyk@chef.io>)
          # Author:: Kyle Goodwin (<kgoodwin@primerevenue.com>)
          # Copyright:: Copyright (c) Chef Software Inc.
          # License:: Apache License, Version 2.0
          #
          # Licensed under the Apache License, Version 2.0 (the "License");
          # you may not use this file except in compliance with the License.
          # You may obtain a copy of the License at
          #
          #     http://www.apache.org/licenses/LICENSE-2.0
          #
          # Unless required by applicable law or agreed to in writing, software
          # distributed under the License is distributed on an "AS IS" BASIS,
          # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
          # See the License for the specific language governing permissions and
          # limitations under the License.
          
          require_relative "log"
          require "chef-config/logger"
          
          # DI our logger into ChefConfig before we load the config. Some defaults are
          # auto-detected, and this emits log messages on some systems, all of which will
          # occur at require-time. So we need to set the logger first.
          ChefConfig.logger = Chef::Log
          
          require "chef-config/config"
          require "chef-utils" unless defined?(ChefUtils::CANARY)
          require_relative "platform/query_helpers"
          
          # Ohai::Config defines its own log_level and log_location. When loaded, it will
          # override the default ChefConfig::Config values. We save them here before
          # loading ohai/config so that we can override them again inside Chef::Config.
          #
          # REMOVEME once these configurables are removed from the top level of Ohai.
          LOG_LEVEL = ChefConfig::Config[:log_level] unless defined? LOG_LEVEL
          LOG_LOCATION = ChefConfig::Config[:log_location] unless defined? LOG_LOCATION
          
          # Load the ohai config into the chef config. We can't have an empty ohai
          # configuration context because `ohai.plugins_path << some_path` won't work,
          # and providing default ohai config values here isn't DRY.
          require "ohai/config"
          
          class Chef
            Config = ChefConfig::Config
          
            # We re-open ChefConfig::Config to add additional settings. Generally,
            # everything should go in chef-config so it's shared with whoever uses that.
            # We make exceptions to that rule when:
            # * The functionality isn't likely to be useful outside of Chef
            # * The functionality makes use of a dependency we don't want to add to chef-config
            class Config
          
              default :event_loggers do
                evt_loggers = []
                if ChefUtils.windows?
                  evt_loggers << :win_evt
                end
                evt_loggers
              end
          
              # Override the default values that were set by Ohai.
              #
              # REMOVEME once these configurables are removed from the top level of Ohai.
              default :log_level, LOG_LEVEL
              default :log_location, LOG_LOCATION
          
              # Ohai::Config[:log_level] is deprecated and warns when set. Unfortunately,
              # there is no way to distinguish between setting log_level and setting
              # Ohai::Config[:log_level]. Since log_level and log_location are used by
              # chef-client and other tools (e.g., knife), we will mute the warnings here
              # by redefining the config_attr_writer to not warn for these options.
              #
              # REMOVEME once the warnings for these configurables are removed from Ohai.
              %i{log_level log_location}.each do |option|
                config_attr_writer option do |value|
                  value
                end
              end
          
            end
          end

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

Lamont_Granquist_OLD · August 12, 2014, 11:45pm

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.

Topic		Replies	Views
Disable chef-client? Chef Infra (archive)	4	3410	October 23, 2014
Chef Client runs twice Chef Infra (archive)	1	734	June 18, 2015
Fwd: Re: Re: Re: Chef Client .... not doing anything Chef Infra (archive)	1	264	December 5, 2014
Execute resource does not wait when chef-client runs in background Chef Infra (archive)	0	734	September 27, 2017
Issues with chef-client service Chef Infra (archive)	3	403	April 4, 2014

Client locking

Related Topics