Upgrade from 2.7 to 3.0, problem with "run_mode" in application.rb

305 views
Skip to first unread message

Forrie

unread,
Sep 28, 2012, 4:38:28 PM9/28/12
to puppet...@googlegroups.com

Just upgraded my puppet master to 3.0.0.  We have a very simple setup.  However, when restarting, I see this error:

Starting puppetmaster: /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application.rb:273:in `run_mode': undefined method `settings' for Puppet:Module (NoMethodError)
from /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application/master.rb:5
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in `gem_original_require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in `require'
from /usr/local/lib/ruby/gems/1.8/gems/puppet-2.7.19/bin/puppetmasterd:3
from /usr/local/bin/puppetmasterd:23:in `load'
from /usr/local/bin/puppetmasterd:23


The code that is triggering this:

    # Sets or gets the run_mode name. Sets the run_mode name if a mode_name is
    # passed. Otherwise, gets the run_mode or a default run_mode
    #
    def run_mode( mode_name = nil)
      if mode_name
        Puppet.settings.preferred_run_mode = mode_name
      end

      return @run_mode if @run_mode and not mode_name

      require 'puppet/util/run_mode'
      @run_mode = Puppet::Util::RunMode[ mode_name || Puppet.settings.preferred_run_mode ]
    end


Anyone else run into this problem?

 

Jeff McCune

unread,
Sep 28, 2012, 5:02:15 PM9/28/12
to puppet...@googlegroups.com
On Fri, Sep 28, 2012 at 1:38 PM, Forrie <for...@gmail.com> wrote:
>
> Just upgraded my puppet master to 3.0.0. We have a very simple setup.
> However, when restarting, I see this error:

Do you happen to be at PuppetConf? If so, I'm up on the second level
and would love to work with you on this issue.

> Starting puppetmaster:
> /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application.rb:273:in
> `run_mode': undefined method `settings' for Puppet:Module (NoMethodError)
> from
> /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.0/lib/puppet/application/master.rb:5
> from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in
> `gem_original_require'
> from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:55:in
> `require'
> from /usr/local/lib/ruby/gems/1.8/gems/puppet-2.7.19/bin/puppetmasterd:3
> from /usr/local/bin/puppetmasterd:23:in `load'
> from /usr/local/bin/puppetmasterd:23

How are you starting the puppet master? I'd like to try and reproduce
this issue as soon as possible. I'm trying to find out if this is
going to be a really common issue or if this is an isolated incident.

In particular, could you provide the exact command line invocation
you're using and any related environment variables?

Also, what platform are you running on, and what ruby version?

It looks like you're somehow getting 2.7.19 _and_ 3.0.0 in your backtraces.

-Jeff

Forrie

unread,
Sep 28, 2012, 5:29:41 PM9/28/12
to puppet...@googlegroups.com
I'm not at PuppetConf, unfortunately.  In this case, all I did was a simple CentOS "service puppetmaster restart" as I have in the past.

But, I wonder if the fact there are older versions still present might contribute to this -- though it shouldn't be reading code from those locations.

I down-rev'd back to 2.7 and it's working fine.  This just seemed like an installation bug to me.

Patrick Carlisle

unread,
Sep 28, 2012, 5:40:19 PM9/28/12
to puppet...@googlegroups.com
On Fri, Sep 28, 2012 at 2:29 PM, Forrie <for...@gmail.com> wrote:
I'm not at PuppetConf, unfortunately.  In this case, all I did was a simple CentOS "service puppetmaster restart" as I have in the past.

But, I wonder if the fact there are older versions still present might contribute to this -- though it shouldn't be reading code from those locations.

Definitely. Your stack trace shows puppetmasterd running out of 2.7 but the main puppet code loaded out of 3.0. This is probably because 3.0 no longer ships a puppetmasterd command (it was deprecated in 2.7 in favor of 'puppet master').

Rubygems allows you to have multiple versions installed at the same time, so probably all you need to do is make sure only 3.0 is installed and then make sure your init script calls puppet master instead of puppetmasterd.

-Patrick

Jeff McCune

unread,
Sep 28, 2012, 5:40:20 PM9/28/12
to puppet...@googlegroups.com
On Fri, Sep 28, 2012 at 2:29 PM, Forrie <for...@gmail.com> wrote:
> I'm not at PuppetConf, unfortunately. In this case, all I did was a simple
> CentOS "service puppetmaster restart" as I have in the past.
>
> But, I wonder if the fact there are older versions still present might
> contribute to this -- though it shouldn't be reading code from those
> locations.
>
> I down-rev'd back to 2.7 and it's working fine. This just seemed like an
> installation bug to me.

Yes, I was able to reproduce a very similar issue. Here's the
situation I think you found yourself in:

Rubygems supports multiple installations of the same gem at different
versions. If you have puppet 2.7.19 installed as a gem, and then run
gem install puppet, then you'll have _both_ 2.7.19 and 3.0.0.

In 3.0.0 we've removed the "puppetmasterd" executable. The
puppetmasterd executable shim generated by rubygems still exists in
your PATH though, which is a problem.

The exception was caused because the shim doesn't specify the version
of the puppet codebase it should load, it just specifies version = ">=
0" which causes the 2.7.19 puppetmasterd executable to cross-load the
3.0.0 puppet ruby library.

This doesn't work.

The work-around I suggest is to switch to using the command "puppet
master" instead of "puppetmasterd" This should work with by 2.7.19
and 3.0.0 and will load the correct library:

$ gem list puppet

*** LOCAL GEMS ***

puppet (3.0.0, 2.7.19)

$ which puppet
/Users/jeff/.rbenv/versions/1.8.7-p358/gemsets/development/bin/puppet

$ puppet --version
3.0.0

Hope this helps,
-Jeff

Forrie

unread,
Sep 28, 2012, 6:31:17 PM9/28/12
to puppet...@googlegroups.com
This is probably also the result and problem with the /etc/init.d script I have -- I think I grabbed them from the source code at some point.   I'll have to see if it is a simple search-and-replace issue for that.

Thanks!

Forrie

unread,
Sep 28, 2012, 7:34:10 PM9/28/12
to puppet...@googlegroups.com
On a tangental note, Puppet 3.0 doesn't ship with init scripts in examples/etc/init.d -- I saw a ticket out there mentioning a need for this.   I'm going to guess some others will be caught with the "puppet master" change.    At least, the latest checkout of the GIT repo doesn't have anything in the directory but "sleeper" which isn't very useful.

Matthaus Owens

unread,
Sep 28, 2012, 7:41:48 PM9/28/12
to puppet...@googlegroups.com
Forrie,

For redhat, look in ext/redhat for the init scripts.
ext/redhat/server.init is what you should replace your puppetmaster
init script with.
(https://github.com/puppetlabs/puppet/blob/3.x/ext/redhat/server.init)

HTH
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/AILE88ZfehoJ.
>
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.



--
Matthaus Owens
Release Manager, Puppet Labs
Reply all
Reply to author
Forward
0 new messages