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

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #12773

Service Status detection does not always work properly on Ubuntu

Added by Hendy Irawan about 4 years ago. Updated about 4 years ago.

Status:Needs DecisionStart date:02/22/2012
Priority:NormalDue date:
Assignee:Hendy Irawan% Done:

0%

Category:service
Target version:-
Affected Puppet version:2.7.10 Branch:
Keywords:Ubuntu,service,status

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

Description

This stems from the fact that not all Ubuntu service status scripts use exit code.

e.g.

$ service mysql status; echo $?
mysql stop/waiting
0

This is the case as of Ubuntu 11.10.

This makes service detection require additional “hasstatus” and “status”, which calls the service status combined with “grep ‘is running’” and similar techniques.

History

#2 Updated by Stefan Schulte about 4 years ago

  • Status changed from Unreviewed to Needs More Information
  • Assignee set to Hendy Irawan

Hi Hendy,

can you please tell how puppet should behave in this situations (or how you think puppet should check if mysql is running)?

From your description I guess you have something like

service { 'mysql':
  ensure => running,
}

and puppet does not start your service eventhough it is currently not running? If that is the case can you please put your resource into a file /tmp/test.pp and run puppet apply -v -d /tmp/test.pp so we can see the debug messages? I guess on ubuntu puppet should pick up the upstart provider and run /sbin/status mysql. What is the output of that command?

#3 Updated by Anonymous about 4 years ago

  • Status changed from Needs More Information to Needs Decision

This is actually a nasty problem: Ubuntu have broken init scripts, since they return 0 (eg: running) from what otherwise looks to be a fully functional script. That is … sad, really. Anyway, what we should do to fix this isn’t yet clear – probably match on the output on Ubuntu and check if it reports running in text, since they can’t get the exit code right.

Thanks for the report, and the links.

#4 Updated by Stefan Schulte about 4 years ago

so /sbin/service $my_service status does not work right? That’s also what I’ve got reading the launchpad bug:

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.

My question: Is this also true for the checkscripts that upstart itself provides (/sbin/status)?

#5 Updated by Glenn Aaldering about 4 years ago

Upstart init scripts do not support exit codes on the status command like sysv init does. When you want to check if a service is running this can be parsed from the output of the status command via the “start/running” or “stop/waiting” output. For example:

# start mysql
mysql start/running, process 32693

# status mysql
mysql start/running, process 32693

# stop mysql
mysql stop/waiting

# status mysql
mysql stop/waiting

According to the upstart service provider in puppet this seems to be implemented in some way:

if (! $?.nil?) && (output =~ /start\//)
    return :running
else
    return :stopped
end

When the status command returns start/running with a PID but the service is not running at all that might be a problem/bug within the upstart script itself. If so, you should file a bug at launchpad for that piece of software.

Also available in: Atom PDF