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 #8346

services falsely presumed running on redhat

Added by Chris Phillips almost 5 years ago. Updated over 2 years ago.

Status:AcceptedStart date:07/11/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:service
Target version:-
Affected Puppet version:2.6.7 Branch:
Keywords:service status stopped restart

We've Moved!

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


Description

I have a number of systems which are frequently having problems centering around various services being believed to be running by puppet when they are actually stopped. I have not seen any examples of the opposite being true however.

Two examples:

I use a nagios check to run puppet, so want to ensure the puppet client service is NOT running. the manifest I use to do this is:

     service { "puppet":
        ensure => stopped,
        enable => false,
        subscribe => File["/etc/puppet/puppet.conf"],
        hasrestart => true,
        hasstatus => true,
     }

And this is normally working just fine, however sometimes a client starts to believe that the service IS running, despite there being NO puppet processes running other than the current one-shot one executing the manifests. This happens if running from a cron job, a nagios check or “puppetd -tv” from command line directly. “/etc/init.d/puppet status” returns that the service is not running, with the right exit code (3). Puppet output on continual manual runs:

notice: /Stage[first]/Puppet/Service[puppet]/ensure: ensure changed ‘running’ to ‘stopped’ notice: Finished catalog run in 13.93 seconds

again and again forever until the manifest is changed, to, for example, say it should be running, let that apply, and then revert back to stopped.

Similarly I need func running on all boxes, sometimes it will stop during a logrotate for unknown reasons, and puppet will refuse to start it despite everything saying it is stopped.

service { "funcd":
    ensure => running,
    enable => true,
    subscribe => File["/etc/func/minion.conf"],
    require => Package["func"],
    hasrestart => true,
    hasstatus => false
}

Again this generally works, but over this weekend 9 boxes has func fail on them, there are NO func processes running, and “/etc/init.d/funcd status” confirms this (textually and exist code 3), and this manifest generally works fine.

This may possibly be related to the use of the hasstatus parameter, it seemed to improve the func service check, but doesn’t influence the puppet service being falsely believed to be running. Or the repetitive nature suggests something is possibly cached on the client?

This is on 2.6.7 on rhel5 & 6, i386 and x86_64.

History

#1 Updated by Nan Liu over 4 years ago

  • Status changed from Unreviewed to Needs More Information
  • Priority changed from High to Normal

This is related to how service status is detected, see following thread for more info: http://groups.google.com/group/puppet-users/browse_thread/thread/dd913b6ce519ea68/f25c773c26255b77?lnk=gst&q=service+debug#f25c773c26255b77

Please provide following output when you encounter one of these issues:

/etc/init.d/funcd status
echo $?
puppet resource service funcd -d
puppet resource service funcd hasstatus=true -d

/etc/init.d/puppet status
echo $?
puppet resource service puppet -d
puppet resource service puppet hasstatus=true -d

Based on the debug output, we will determine whether this warrants further investigation.

#2 Updated by Konstantin Ryabitsev about 4 years ago

  • Status changed from Needs More Information to Closed

I have a similar issue with a service running on rhel6, except the service is certmaster. Here is the output you requested:

[root@logs init.d]# /etc/init.d/certmaster status
certmaster is not running
[root@logs init.d]# echo $?
3
[root@logs init.d]# puppet resource service certmaster -d
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
debug: Service[certmaster](provider=redhat): Executing '/sbin/service certmaster status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig certmaster'
service { 'certmaster':
  ensure => 'running',
  enable => 'false',
}
[root@logs init.d]# puppet resource service certmaster hasstatus=true -d
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
debug: Loaded state in 0.00 seconds
debug: Service[certmaster](provider=redhat): Executing '/sbin/service certmaster status'
debug: Finishing transaction 70363726088120
debug: Storing state
debug: Stored state in 0.03 seconds
debug: Service[certmaster](provider=redhat): Executing '/sbin/service certmaster status'
service { 'certmaster':
  ensure => 'running',
}

[root@logs init.d]# /etc/init.d/puppet status
puppetd (pid  31557) is running...
[root@logs init.d]# echo $?
0
[root@logs init.d]# puppet resource service puppet -d
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig puppet'
service { 'puppet':
  ensure => 'running',
  enable => 'true',
}
[root@logs init.d]# puppet resource service puppet hasstatus=true -d
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not exist
debug: Loaded state in 0.00 seconds
debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet status'
debug: Finishing transaction 70100653891600
debug: Storing state
debug: Stored state in 0.05 seconds
debug: Service[puppet](provider=redhat): Executing '/sbin/service puppet status'
service { 'puppet':
  ensure => 'running',
}

#3 Updated by Konstantin Ryabitsev about 4 years ago

Hint — it worked after I removed redhat-lsb package. Looks like when scripts use lsb functions instead of /etc/init.d/functions, puppet incorrectly identifies current state.

#4 Updated by Anonymous about 4 years ago

Konstantin Ryabitsev wrote:

Hint — it worked after I removed redhat-lsb package. Looks like when scripts use lsb functions instead of /etc/init.d/functions, puppet incorrectly identifies current state.

Wow. Thanks for the update – that is very odd.

#5 Updated by Anonymous about 4 years ago

  • Status changed from Closed to Accepted

#6 Updated by Sven T almost 4 years ago

Is there a real solution, something without the workaround? I happen to need the lsb package… :/

#7 Updated by Mike Lehner over 2 years ago

Has anyone gotten this to work without removing the redhat-lsb package? Is that the only solution to this problem? We’re on Puppet 3.2 now and I’m really surprised this is still an issue, and even more surprised it hasn’t affected more people.

I removed the redhat-lsb package and I seem to still have this issue with the ActiveMQ service so something else but related must be up with that as well.

Also available in: Atom PDF