Puppet users - Nov 2012 - Issue with service => disabled and stopped

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.

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

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

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

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

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

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

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

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.

On Mon, Nov 19, 2012 at 4:37 PM, Forrie <forrie@gmail.com>
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.
>
> I am running:
>
> # puppet --version
> 2.7.19
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>


-- 
Matthaus Owens
Release Manager, Puppet Labs

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

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



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

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.

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

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
 

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