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

Bug #8592

Non-existent service succeeds with hasstatus=true on RHEL based OSes

Added by Dominic Maraglia about 3 years ago. Updated almost 3 years ago.

Status:InvestigatingStart date:07/22/2011
Priority:LowDue date:
Assignee:-% Done:

0%

Category:service
Target version:-
Affected Puppet version:2.6.4 Branch:
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

Running “puppet resource service foo hasstatus=true” on RHEL derived OSes succeeds. Correct behaviour is to fail indicating and invalid service.

[root@rhel50-x86-64 init.d]# puppet resource service pe-puppet hasstatus=true
service { 'pe-puppet':
    ensure => 'stopped'
}
[root@centos-55-64-1 ~]# puppet resource service foo hasstatus=true
service { 'foo':
    ensure => 'stopped'
}

Related issues

Related to Puppet - Bug #4123: puppet resource service does not correctly list all runin... Closed 07/01/2010

History

#1 Updated by Stefan Schulte about 3 years ago

I dont know if I can agree here. In the end the service foo you asked for is not running. Also what should happen if I have a manifest like

server { 'foo':
  ensure => stopped,
}

I dont care if foo is installed or not, I just don’t want that service foo is running. I think it whould be a bad idea to raise an error in case there is no such service foo. And in my opinion puppet resource should behave the same.

#2 Updated by Peter Meier about 3 years ago

  • Priority changed from High to Normal

I dont care if foo is installed or not, I just don’t want that service foo is running. I think it whould be a bad idea to raise an error in case there is no such service foo. And in my opinion puppet resource should behave the same.

  • 1, how should it fail if the service is not present? Catalog fail would make it very hard to remove/disable services.

#3 Updated by Nigel Kersten about 3 years ago

  • Priority changed from Normal to Low

I’m not sure we have correct defined behavior here.

Given the service ensure property doesn’t cover actual existence, I’m quite sure we have different behaviors on different platforms and service providers.

For example, the launchd provider definitely fails in this situation:

$ puppet resource service foobar
Could not run: Unable to find launchd plist for job: foobar

but I think the init.d providers have all behaved like this for a while.

It would be good to bring some consistent semantics to all the service providers.

Also available in: Atom PDF