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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
