Issue with service => disabled and stopped

[Forrie]

I have a simple manifest that I'm using to keep unwanted services from
running on an array of Linux systems. On my test host, I see these
two services repeatedly come up in the puppet.log, even tho they are
not running and are chkconfig set to off:

service { "cups":
enable => false,
ensure => stopped,
}

service { "cups-config-daemon":
enable => false,
ensure => stopped,
}

The log:

Nov 16 19:11:39 test-fms puppet-agent[6530]: (/Stage[main]/Disabled-
services/Service[cups-config-daemon]/ensure) ensure changed 'running'
to 'stopped'
Nov 16 19:11:40 test-fms puppet-agent[6530]: (/Stage[main]/Disabled-
services/Service[hidd]/ensure) ensure changed 'running' to 'stopped'

verify in chkconfig:

cups-config-daemon 0:off 1:off 2:off 3:off 4:off 5:off 6:off
hidd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

This shows up every time puppet agent runs for this host. Why would
this be happening?

This is using puppet 2.7.19 and the latest ruby 1.8.7.



Thanks.

[Steven Nemetz]

If it is happening every time, it is usually an issue with init script. Puppet is not understanding the output of the init script, so it is not saving the correct state.
Run the init script manually and see what it is returning. If it is not obvious, run puppet with --debug and see the exact command puppet is running

Steven

 

> Date: Fri, 16 Nov 2012 16:15:42 -0800
> Subject: [Puppet Users] Issue with service => disabled and stopped
> From: for...@gmail.com
> To: puppet...@googlegroups.com

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[jcbollinger]

On Friday, November 16, 2012 6:51:19 PM UTC-6, Steven wrote:

If it is happening every time, it is usually an issue with init script. Puppet is not understanding the output of the init script, so it is not saving the correct state.

Minor correction: it's not about what state Puppet "saves", but rather about what state Puppet detects.

Supposing that Puppet is using the "redhat" Service provider (since you mention chkconfig), it is determining the services' state via the exit code of command "/sbin/service <servicename> status", with reference to the LSB standard for initscript exit codes.  Hence Steven's suggestion to
 

Run the init script manually and see what it is returning. If it is not obvious, run puppet with --debug and see the exact command puppet is running

I note, however, that Redhat Linuxes and their derivatives (i.e. RHEL, Fedora, CentOS, Scientific Linux, etc.) are very reliable with respect to standards conformance in this area, so it's a bit strange to see a problem such as you describe on a system that appears to be in that class.

Are you certain that the agent is running Puppet 2.7.19?  The Service type has a parameter 'hasstatus' which used to default to false, but now defaults to true.  Back when it defaulted to false, you would typically want to set it true where your initscript provided a standard-compliant 'status' command, and elsewhere you would sometimes need to set an explicit status testing command via the 'status' parameter.

Of course, the flip side is that with recent Puppet, if your initscript does not support 'status' correctly, and you can't or won't fix it, then you need to tell Puppet "hasstatus => false" and "status => <command-to-determine-status>".


John

[Forrie]

Thanks for the explanation, I appreciate it.

These services are provided by Redhat as are the init scripts, which
report:


# /etc/init.d/cups-config-daemon status
cups-config-daemon is obsolete

# /etc/init.d/hidd status
hidd is stopped


I can see where the first one is unexpected to Puppet.

I am running:

# puppet --version
2.7.19

[Matthaus Owens]

Both of these init scripts always return 0. Puppet assumes that the
init script will return 0 as a status for a running service and
nonzero for a stopped service. Because of this, when Puppet calls
`service hidd status` to see if hidd needs to be stopped, it thinks it
does, as status returns 0.

hidd ships with a deficient init script. It makes the right calls to
start, stop, and get the status of the hidd service, but it never does
anything with the returns from those calls so it always falls through
to the bottom of the script where 0 is returned.

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

--
Matthaus Owens
Release Manager, Puppet Labs

[jcbollinger]

On Monday, November 19, 2012 6:37:28 PM UTC-6, Forrie wrote:

Thanks for the explanation, I appreciate it.

These services are provided by Redhat as are the init scripts, which
report:


# /etc/init.d/cups-config-daemon status
cups-config-daemon is obsolete

# /etc/init.d/hidd status
hidd is stopped


I can see where the first one is unexpected to Puppet.

What Matthaus said.  But also, I emphasize what he breezed over: it is the exit code of the 'service' command that Puppet considers, as I wrote earlier.  Nothing the command sends to its output or error stream is relevant to Puppet's evaluation.  In the shell, you can get the exit code of the last foreground process run by that shell from the variable $?.  Example:

/etc/init.d/cups-config-daemon status
echo $?


John

[Forrie]

Thanks, I went ahead and added an "exit 1" at the bottom of each of
these scripts to shut it up. At least, in the case of the cups-
config-daemon, it's been deprecated so I can just remove that check.
HIDD is another issue. Most of the init.d scripts use RETVAL=$?
after the status) query -- so that's hooked in somewhere to the
functions perhaps and that it doesn't work properly with HIDD is
"really" a bug, per se.

[jcbollinger]

On Tuesday, November 20, 2012 6:11:17 PM UTC-6, Forrie wrote:

Thanks, I went ahead and added an "exit 1" at the bottom of each of
these scripts to shut it up.

That's probably not quite right, but maybe it will work well enough for you.

 

  At least, in the case of the cups-
config-daemon, it's been deprecated so I can just remove that check.
HIDD is another issue.   Most of the init.d scripts use RETVAL=$?
after the status) query -- so that's hooked in somewhere to the
functions perhaps and that it doesn't work properly with HIDD is
"really" a bug, per se.

Yes, it is a bug in the initscript.  They both are.  You should consider filing a ticket with your distro.


John