The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #12494

When cwd is invalid, puppet prints a stack trace

Added by Ben Ford about 2 years ago. Updated about 2 years ago.

Status:AcceptedStart date:02/07/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Doh!
Target version:3.x
Affected Puppet version: Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

[root@henry ~]# mkdir test
[root@henry ~]# cd test
[root@henry test]# puppet apply /etc/puppetlabs/puppet/manifests/resource_defaults.pp 
notice: /Stage[main]//File[/tmp/default]/mode: mode changed '644' to '755'
notice: Finished catalog run in 0.05 seconds
[root@henry test]# rm -rf ../test
[root@henry test]# puppet apply /etc/puppetlabs/puppet/manifests/resource_defaults.pp 
/opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `expand_path': No such file or directory - getcwd (Errno::ENOENT)
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `look_in'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `collect'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `look_in'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:54
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:1:in `require'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:1
    from /usr/local/bin/puppet:3:in `require'
    from /usr/local/bin/puppet:3
[root@henry test]# 

Related issues

Related to Puppet - Bug #4253: puppetmaster started in a non accessible directory for th... Accepted 07/16/2010
Blocked by Puppet - Refactor #7749: Bootstrapping Puppet in Ruby code has nasty scope cycles... Closed 06/01/2011

History

#1 Updated by Ben Ford about 2 years ago

Oh, gross. Again, with the pre tags. :)

[root@henry ~]# mkdir test
[root@henry ~]# cd test
[root@henry test]# puppet apply /etc/puppetlabs/puppet/manifests/resource_defaults.pp 
notice: /Stage[main]//File[/tmp/default]/mode: mode changed '644' to '755'
notice: Finished catalog run in 0.05 seconds
[root@henry test]# rm -rf ../test
[root@henry test]# puppet apply /etc/puppetlabs/puppet/manifests/resource_defaults.pp 
/opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `expand_path': No such file or directory - getcwd (Errno::ENOENT)
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `look_in'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `collect'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:49:in `look_in'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/plugins.rb:54
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:1:in `require'
    from /opt/puppet/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:1
    from /usr/local/bin/puppet:3:in `require'
    from /usr/local/bin/puppet:3
[root@henry test]#

#2 Updated by Daniel Pittman about 2 years ago

  • Description updated (diff)

#3 Updated by Daniel Pittman about 2 years ago

  • Category set to Doh!
  • Status changed from Unreviewed to Accepted
  • Assignee set to Chris Price

Confirmed, this fails in exactly that way. Unfortunately, it isn’t trivial to fix – cut down the first failure, hit another, and another, and so on.

That said, we are hardly the only tool that will behave oddly if the working directory is unlinked from the tree, so we should probably fix it globally by changing to something consistent; ‘/’ would be a standard choice…

#4 Updated by Peter Meier about 2 years ago

If you’re considering to change puppet’s cwd while executing, there have been also a discussion about a (as far as I would say) similar issue with the master: #4253 – I just remembered that bug and the discussion around it, when reading this bug. Maybe one could solve two problems with one fix?

#5 Updated by Chris Price about 2 years ago

I agree with the consensus on #4253 that the “—no-daemonize” argument should not cause any significant difference in behavior compared to the daemon mode, and can see the case to go ahead and cwd for that since we are doing it for the daemon case.

I also agree that doing that cwd at an even higher level (e.g., somewhere where it would take effect during an ‘apply’) would get rid of the error demonstrated on this ticket.

However, I’m not 100% sure that users would expect this same behavior for, e.g., “puppet apply”. At the very least we’d have to be careful to have expanded any relative paths provided as command line args before we changed the working directory; otherwise, something like “puppet apply ./foo/bar.pp” would yield very confusing results.

#6 Updated by Daniel Pittman about 2 years ago

Chris Price wrote:

However, I’m not 100% sure that users would expect this same behavior for, e.g., “puppet apply”. At the very least we’d have to be careful to have expanded any relative paths provided as command line args before we changed the working directory; otherwise, something like “puppet apply ./foo/bar.pp” would yield very confusing results.

Supporting that is fine; once the input file is read, none of the other behaviour of the system should be influenced by the CWD – you can’t use relative paths in your manifest content, so that should (hopefully) make it reasonably sane to work with…

#7 Updated by Chris Price about 2 years ago

  • Target version set to 3.x

#8 Updated by Chris Price about 2 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee changed from Chris Price to Daniel Pittman

Hey Daniel… I’d assigned this to myself thinking that I might end up seeing an easy opportunity to deal with it during my work on #7749 (bootstrapping). That didn’t really happen… and I’m inclined to just throw this one back into the pool because it doesn’t seem as urgent as some other tickets. Happy to keep it in my queue if you feel differently, though.

#9 Updated by Daniel Pittman about 2 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Daniel Pittman)

Chris Price wrote:

Hey Daniel… I’d assigned this to myself thinking that I might end up seeing an easy opportunity to deal with it during my work on #7749 (bootstrapping). That didn’t really happen… and I’m inclined to just throw this one back into the pool because it doesn’t seem as urgent as some other tickets. Happy to keep it in my queue if you feel differently, though.

If you are not working on it, no need to keep yourself assigned. :)

Also available in: Atom PDF