puppet in lucid does not support upstart status

Bug #551544 reported by Nick Moffitt
46
This bug affects 8 people
Affects Status Importance Assigned to Milestone
puppet (Ubuntu)
Fix Released
High
Mathias Gug
Lucid
Fix Released
High
Mathias Gug

Bug Description

Binary package hint: puppet

Puppet does not currently have an "upstart" provider for the service resource. As such, it relies on upstart's sysV compatability, which is somewhat limited.

The key problem here is that features such as "ensure => running" cannot rely on "hasstatus => true" for any service that has an upstart init script. Upstart's status command appears to consider the exit code to be an actual error status *for upstart itself*, and does not conform to the status-based exit codes specified by sysV init scripts.

The result is that the only way to know if a service is running or stopped in puppet on lucid is to set "hasstatus => false" and then define a regular expression for grepping the process table--this is far from optimal.

Compounding this, puppet's init.d provider considers it appropriate to run "update-rc.d" as though the sysV script were the preferred init script.

What needs to happen very soon is either an upstart provider is written for puppet's service resource (presumably one that falls back to the sysv script if no upstart script is found), or the sysV compatibility scripts need to interpret the "stop/waiting" output of the upstart status command and translate that to the standard exit code. Until then, lucid's puppet is somewhat crippled.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: puppet 0.25.4-2ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-18.27-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-18-generic x86_64
Architecture: amd64
Date: Tue Mar 30 10:38:40 2010
EcryptfsInUse: Yes
PackageArchitecture: all
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: puppet

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :
description: updated
description: updated
Mathias Gug (mathiaz)
Changed in puppet (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Mathias Gug (mathiaz)
Changed in puppet (Ubuntu Lucid):
importance: Medium → High
Revision history for this message
Nigel Kersten (nigelk) wrote :

I'll try and find the bug in a second, but apparently the lack of any return codes from /etc/init.d/foo status when a service has been upstarted is a bug.

Ultimately I feel puppet needs an initctl based service provider.

Revision history for this message
Nigel Kersten (nigelk) wrote :

To clarify, assuming the status situation with upstarted init.d scripts is resolved, I don't see any major reason why the existing provider wouldn't continue to at least function well enough for users?

The update-rc situation isn't ideal, which is why I suggested an initctl based provider, which really should be trivial to write given it already supports start, stop, status and list.

I don't see Puppet upstream integrating such a provider into the 0.25.x series as the commit rules are now for no new functionality to go into minor updates in a release series, but if someone puts it together soon, it can definitely make it into 'rowlf', the next major version.

Revision history for this message
Andrew Pollock (apollock) wrote :
Thierry Carrez (ttx)
Changed in puppet (Ubuntu Lucid):
milestone: none → ubuntu-10.04
Thierry Carrez (ttx)
Changed in puppet (Ubuntu Lucid):
assignee: nobody → Mathias Gug (mathiaz)
Revision history for this message
Mathias Gug (mathiaz) wrote :

Here is a proposal:

Add a statuscmd function in the puppet debian service provider. If the initscript script is a symlink to /lib/init/upstart-job, use the following command as the statuscmd instead of the default [initscript, :status] defined in the init provider:

 sh -c "invoke-rc.d SERVICE status | grep -q '^SERVICE.*running'"

I'd need to verify whether upstart has been i18n.

Changed in puppet (Ubuntu Lucid):
status: Confirmed → Triaged
Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

i18n aside, that seems like an elegant workaround given the deadlines involved.

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

Presumably even if there is i18n, you could force LANG=C or similar?

Revision history for this message
Mathias Gug (mathiaz) wrote :

As mentioned on IRC:

<slangasek> ttx: bug #551544> possibly simpler to just get this fixed in upstart for release; can you make sure mathiaz talks with Keybuk
about this?
<slangasek> (bug #552786 is the corresponding upstart bug)
<ttx> slangasek: yes

Mathias Gug (mathiaz)
Changed in puppet (Ubuntu Lucid):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package puppet - 0.25.4-2ubuntu6

---------------
puppet (0.25.4-2ubuntu6) lucid; urgency=low

  * Fix init service provider to correctly check the status of services
    using upstart jobs (LP: #551544).
  * Package spec/ tests so that both test/ and spec/ tests can be run.
 -- Mathias Gug <email address hidden> Tue, 13 Apr 2010 18:33:05 -0400

Changed in puppet (Ubuntu Lucid):
status: In Progress → Fix Released
Revision history for this message
Hendy Irawan (ceefour) wrote :

It says fixed but I don't think it's fixed. I'm using Ubuntu 11.10 with Puppet 2.7.10 and still having this problem.

I also filed Puppet bug #12773: Service Status detection does not always work properly on Ubuntu in https://projects.puppetlabs.com/issues/12773

See also forum thread: puppet service status checks - http://ubuntuforums.org/showthread.php?t=1865856

Revision history for this message
lorello (lorello) wrote :

Hi, I've the same problem on Lucid Ec2 hosts: ssh service does not restart correctly using hasstatus => true, even expliciting upstart as provider

I'm using Puppet version 2.7.14 from skettler's PPA

Revision history for this message
Glenn Aaldering (glennaaldering) wrote :

Hi Lorello,

In the puppet source code at github you can see how the status is checked via upstart:

https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/upstart.rb

The is a search for 'start' on the status output. So if ssh is running and status ssh gives the following output 'ssh start/running, process xxxxx' then puppet should know the service is running. Also you can check https://projects.puppetlabs.com/issues/12773 since it has some more information on this as well.

How exactly can we reproduce your problem?

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

Lorello,
I believe this issue is being tracked at https://projects.puppetlabs.com/issues/14297 and there is a pull request in that should resolve the issue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.