Bug #2237
puppetd sometimes does not create $yamlclientdir automatically
| 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 KayserTo: 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