[chef] Re: Re: transient dpkg lock issues?

[Matthew Todd < >]

On Aug 6, 2009, at 10:53 PM, Joe Van Dyk wrote:

> Is the system setup to automatically run apt-get update?

On Aug 6, 2009, at 11:07 PM, Bryan McLellan wrote:

> Any chance you are running apt elsewhere?


Thanks Joe, thanks, Bryan!

You guys provided just the lateral-thinking stimulus I needed:

Short version:
I had 2 chef clients running at the same time!

Long version:
Rather than go through a separate "just install chef-client"  
bootstrapping phase, I thought I'd bring up my system by manually  
running chef-client the first time, with the appropriate config file  
pointing to my chef-server. (This was motivated by wanting to avoid  
duplicating my cookbooks: I'm using a slightly modified template for / 
etc/chef/client.rb that supports http auth, so I couldn't use the  
stock bootstrap-latest.tar.gz.)

This is a bad idea.

Halfway through the convergence phase of my manual chef-client run,  
runit sprang into being with its own ongoing chef-client run, which  
then raced from time to time for the dpkg lock with the remaining  
half of my manual convergence phase. D'oh!

So, I'm backing off this strategy and making my own bootstrapping  
tarball.

Cheers! Long live Chef!

-- Matthew



As an aside, dropping the following monkey-patch into one of my  
cookbooks' libraries was a huge help in tracking down the problem:

class Chef::Provider::Package::Apt < Chef::Provider::Package
  def install_package(name, version)
    currently_running_processes = `ps axf`
    run_command(
      :command => "apt-get -q -y#{expand_options 
(@new_resource.options)} install #{name}=#{version}",
      :environment => { "DEBIAN_FRONTEND" => "noninteractive" }
    )
  rescue Chef::Exceptions::Exec
    Chef::Log.error("Running processes were:\n# 
{currently_running_processes}")
    raise
  end
end