puppet in lucid does not support upstart status

Bug #551544 reported by Nick Moffitt on 2010-03-30
This bug affects 8 people
Affects Status Importance Assigned to Milestone
puppet (Ubuntu)
Mathias Gug
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
Uname: Linux 2.6.32-18-generic x86_64
Architecture: amd64
Date: Tue Mar 30 10:38:40 2010
EcryptfsInUse: Yes
PackageArchitecture: all
 PATH=(custom, user)
SourcePackage: puppet

Nick Moffitt (nick-moffitt) wrote :
description: updated
description: updated
Mathias Gug (mathiaz) on 2010-03-30
Changed in puppet (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Mathias Gug (mathiaz) on 2010-03-30
Changed in puppet (Ubuntu Lucid):
importance: Medium → High
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.

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.

Andrew Pollock (apollock) wrote :
Thierry Carrez (ttx) on 2010-04-01
Changed in puppet (Ubuntu Lucid):
milestone: none → ubuntu-10.04
Thierry Carrez (ttx) on 2010-04-09
Changed in puppet (Ubuntu Lucid):
assignee: nobody → Mathias Gug (mathiaz)
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
Nick Moffitt (nick-moffitt) wrote :

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

Nick Moffitt (nick-moffitt) wrote :

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

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) on 2010-04-13
Changed in puppet (Ubuntu Lucid):
status: Triaged → In Progress
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
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

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

Hi Lorello,

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


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?

Matthaus Owens (matthaus-m) wrote :

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  Edit
Everyone can see this information.

Other bug subscribers