Bug #2237

puppetd sometimes does not create $yamlclientdir automatically

Added by Derek Whayman about 3 years ago. Updated 9 months ago.

Status:Accepted Start date:05/11/2009
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:executables
Target version:2.7.x
Affected Puppet version:0.25.0 Branch:
Keywords:
Votes: 0

Description

Workaround’s quite obvious :–)

Cheers, Derek

History

Updated by Derek Whayman about 3 years ago

  • Affected Puppet version changed from 0.24.8 to 0.25.0

Updated by James Turnbull about 3 years ago

  • Status changed from Unreviewed to Accepted
  • Assignee set to Luke Kanies
  • Target version set to 0.25.0

Updated by Luke Kanies almost 3 years ago

  • Status changed from Accepted to Needs More Information
  • Assignee changed from Luke Kanies to Puppet Community

Why does it need that directory? Only puppetd should need it.

Updated by Derek Whayman almost 3 years ago

Hi chaps

Looking at the files in there I swear it’s server-side caching of client details! The dir doesn’t exist on the client, and on the server I see ./facts and ./node – the facts sent back to the PM broadly.

To be honest I was expecting the ./node dir to be the entire localconfig.yaml file but they are just the facts, m'lud.

<0> root@engpsr0170.etf.barcapetf.com (0 jobs)
 /var/lib/puppet/yaml
  # find
.
./node
./node/engpsr0171.etf.barcapetf.com.yaml
./node/engpsr0170.etf.barcapetf.com.yaml
./facts
./facts/engpsr0171.etf.barcapetf.com.yaml
./facts/engpsr0170.etf.barcapetf.com.yaml

Cheers, Derek

Updated by Luke Kanies almost 3 years ago

The directory named ‘yaml’ is the server yaml directory, not the client yaml directory (normally named ‘client_yaml’).

Can you provide a stack trace from the process that is failing because this directory doesn’t exist?

All appropriate yaml dirs get created fine for me…

Updated by Derek Whayman almost 3 years ago

Sorry, you’re right, must have gotten confused. On the client puppetd run:

info: Caching catalog for engpsr0170.etf.barcapetf.com
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/yaml.rb:36:in `mkdir'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/yaml.rb:36:in `save'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:201:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector.rb:51:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:94:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:425:in `thinmark'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/core_ext/benchmark.rb:10:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:424:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:93:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:132:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/1.8/sync.rb:229:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:130:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/sbin/puppetd:159
err: Could not retrieve catalog from remote server: No such file or directory - /var/lib/puppet/client_yaml/catalog
err: Could not retrieve catalog; skipping run

Updated by Luke Kanies almost 3 years ago

  • Subject changed from puppetmasterd does not create $yamlclientdir automatically to puppetd sometimes does not create $yamlclientdir automatically

Okay, so it’s puppetd, not puppetmasterd. But… anyone else having this issue?

What’s your exact sequence to reproduce, starting from a missing client confdir/vardir?

Updated by Derek Whayman almost 3 years ago

So, we start off with $vardir=/var/lib/puppet This exists by way of either our build process, the puppet RPM or autocreation (or possibly all three).

Then I fire off puppetd as above. Judging from the stack trace, it tries to create /var/lib/puppet/client_yaml/catalog, and fails because /var/lib/puppet/client_yaml does not exist. A manual mkdir of /var/lib/puppet/client_yaml is sufficient to get puppetd up and running.

Best regards, Derek

Updated by Luke Kanies almost 3 years ago

  • Category set to executables
  • Status changed from Needs More Information to Accepted

Looks like puppetd’s setup method just needs a ‘Puppet.settings.use(:main, :ssl, :puppetd)’ call.

Updated by Luke Kanies almost 3 years ago

  • Status changed from Accepted to Ready For Checkin
  • Assignee changed from Puppet Community to James Turnbull

Fixed in the tickets/master/2237 branch in my repo.

Updated by James Turnbull almost 3 years ago

  • Status changed from Ready For Checkin to Closed

Pushed in commit:bc1445b5cefb5742ca906632cc99a82a769ead97 in branch master.

Updated by Nigel Kersten over 1 year ago

  • Status changed from Closed to Re-opened
  • Target version deleted (0.25.0)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557769


Sebastian Kayser 
To: 557769@bugs.debian.org
Subject: puppet: /var/lib/puppet/client_yaml should be created
Date: Mon, 26 Apr 2010 11:10:46 +0200
Greetings,

as I just ran into the same problem, here is the likely cause for this
reported bug: puppetd creates those local directories (e.g. client_yaml)
with the proper permissions if required, but it doesn't do so when being
run in --noop mode (--noop can be seen in Adrian's previous comment).

Could be helpful if either
a) the package shipped those directories out-of-the-box
b) puppetd would create the directories even when called with --noop
c) puppetd would emit a notice pointing out the --noop issue

Sebastian

Updated by James Turnbull about 1 year ago

  • Status changed from Re-opened to Needs Decision
  • Assignee changed from James Turnbull to Nigel Kersten

Updated by Nigel Kersten 9 months ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Target version set to 2.7.x

Also available in: Atom PDF