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

Bug #14036

Allow puppet to handle upstart better

Added by Matthaus Owens over 2 years ago. Updated almost 2 years ago.

Status:Re-openedStart date:04/17/2012
Priority:NormalDue date:
Assignee:Jeff Weiss% Done:

0%

Category:-
Target version:2.7.15
Affected Puppet version: Branch:https://github.com/puppetlabs/puppet/pull/681
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

Ubuntu patches their puppet with the following patch (included below and as http://paste.ubuntu.com/891624/). It would be awesome to know if this patch is sound enough to be used against our puppet. If so I’m happy to put a pull in with it. Mostly I would like to know if it is sound enough to patch PE with for the upcoming Precise release.

--- puppet-2.7.11.orig/lib/puppet/provider/service/init.rb
+++ puppet-2.7.11/lib/puppet/provider/service/init.rb
@@ -129,7 +129,15 @@ Puppet::Type.type(:service).provide :ini
# we just return that; otherwise, we return false, which causes it to
# fallback to other mechanisms.
def statuscmd
-    (@resource[:hasstatus] == :true) && [initscript, :status]
+      if @resource[:hasstatus] == :true then 
+          # Workaround the fact that initctl status command doesn't return
+          # proper exit codes. Can be removed once LP: #552786 is fixed.
+          if File.symlink?(initscript) && File.readlink(initscript) == "/lib/init/upstart-job" then
+              ['sh', '-c', "LANG=C invoke-rc.d #{File::basename(initscript)} status | grep -q '^#{File::basename(initscript)}.*running'" ]
+          else
+              [initscript, :status ]
+          end
+      end
end
end
--- /dev/null

History

#1 Updated by Jeff Weiss over 2 years ago

The ticket referenced in the patch hasn’t had any updates in nearly two years.

#2 Updated by Jeff Weiss over 2 years ago

I have a little reservation about this going into init.statuscmd as opposed to upstart.statuscmd. Upstart seems like it’s a better option.

Makes sense why they patched init though, they don’t have to worry about any other platforms.

#3 Updated by Jeff Weiss over 2 years ago

Testing out on pe-ubuntu-lucid vm, using puppet 2.7.13.

puppet apply -e " service { "plymouth":, ensure => running }"

As noted above this does not actually start the service because of an “incorrect” return code from upstart.

However, if I explicitly set the provider to be upstart, both of the following work as expected.

root@pe-ubuntu-lucid:~# status plymouth
plymouth stop/waiting
root@pe-ubuntu-lucid:~# puppet apply -e " service { "plymouth":, ensure => running, provider => upstart }"
notice: /Stage[main]//Service[plymouth]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.38 seconds
root@pe-ubuntu-lucid:~# status plymouth
plymouth start/running, process 17452
root@pe-ubuntu-lucid:~# puppet apply -e " service { "plymouth":, ensure => stopped, provider => upstart }"
notice: /Stage[main]//Service[plymouth]/ensure: ensure changed 'running' to 'stopped'
notice: Finished catalog run in 0.19 seconds
root@pe-ubuntu-lucid:~# status plymouth
plymouth stop/waiting

#4 Updated by Jeff Weiss over 2 years ago

At least on lucid, we have some services that are upstart jobs and some that are init scripts. Requiring the user to explicitly set the provider for one or the other is not the right approach.

After some mucking about with upstart.rb, I got something that enables this:

root@pe-ubuntu-lucid:~# puppet apply -e " service { ['plymouth', 'postfix']:, ensure => running,  }"
notice: /Stage[main]//Service[postfix]/ensure: ensure changed 'stopped' to 'running'
notice: /Stage[main]//Service[plymouth]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.33 seconds
root@pe-ubuntu-lucid:~# puppet apply -e " service { ['plymouth', 'postfix']:, ensure => stopped,  }"
notice: /Stage[main]//Service[postfix]/ensure: ensure changed 'running' to 'stopped'
notice: /Stage[main]//Service[plymouth]/ensure: ensure changed 'running' to 'stopped'
notice: Finished catalog run in 0.26 seconds

where plymouth is an upstart job and postfix as an initscript.

I still need to write a number of tests, but the feature branch is underway at jeffweiss/puppet/ticket/2.7.x/14036_handle_upstart_better

#5 Updated by Jeff Weiss over 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/puppet/pull/681

Created pull request targeted to 2.7.x. You should be able to pull this off as a patch and apply it directly to PE.

#6 Updated by Anonymous over 2 years ago

  • Project changed from Release Engineering to Puppet
  • Target version deleted (PE 2.5.2)

#7 Updated by Anonymous over 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release
  • Target version set to 2.7.15

#8 Updated by Moses Mendoza over 2 years ago

  • Target version changed from 2.7.15 to 2.7.14

#9 Updated by Moses Mendoza over 2 years ago

  • Status changed from Merged - Pending Release to Closed

released in 2.7.14rc3

#10 Updated by Richard Crowley over 2 years ago

  • Status changed from Closed to Re-opened
  • Target version changed from 2.7.14 to 2.7.15

This patch definitely seems to have broken service resources which explicitly declare provider => "upstart" and don’t have the /lib/init/upstart-job symlink. I get

Could not evaluate: Could not find init script for '...'

errors for all my Upstart services which work fine with 2.7.13. They’re all declared

service { "...":
    ensure => running,
    hasstatus => true,
    provider => "upstart",
}

#11 Updated by Tim Mooney over 2 years ago

I’m seeing the exact same thing Richard is.

err: /Stage[main]/Statsd::Service/Service[statsd]: Could not evaluate: Could not find init script for 'statsd'

Note that prior to 2.7.14, we were applying a very minor patch to provider/service/upstart.rb, so that :redhat was also a valid option for upstart:

Index: puppet-2.7.9/lib/puppet/provider/service/upstart.rb
===================================================================
--- puppet-2.7.9.orig/lib/puppet/provider/service/upstart.rb
+++ puppet-2.7.9/lib/puppet/provider/service/upstart.rb
@@ -5,7 +5,7 @@ Puppet::Type.type(:service).provide :ups
   on Ubuntu. For `upstart` documentation, see <http://upstart.ubuntu.com/>.
   "
   # confine to :ubuntu for now because I haven't tested on other platforms
-  confine :operatingsystem => :ubuntu #[:ubuntu, :fedora, :debian]
+  confine :operatingsystem => [:ubuntu,:redhat,:centos]

   commands :start   => "/sbin/start",
            :stop    => "/sbin/stop",

With 2.7.14, that’s no longer enough because of the new tests for is_upstart?.

RHEL 6.x uses upstart, but it does not include /lib/init (or /lib64/init).

It does have the directory /etc/init/ and the *.conf files in that directory control the upstart services. It also does have /sbin/initctl and all the symlinks in /sbin that service/upstart.rb is expecting.

Also available in: Atom PDF