Grokbase › Groups › Puppet › puppet-users › November 2012
FAQ
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.

Search Discussions

  • Steven Nemetz at Nov 17, 2012 at 12:51 am ⇧
    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.
  • Jcbollinger at Nov 19, 2012 at 2:27 pm ⇧

    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.
  • Forrie at Nov 20, 2012 at 12:37 am ⇧
    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 at Nov 20, 2012 at 5:38 am ⇧
    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 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.
  • Jcbollinger at Nov 20, 2012 at 1:58 pm ⇧

    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.
  • Forrie at Nov 21, 2012 at 12:18 am ⇧
    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.
  • Jcbollinger at Nov 26, 2012 at 4:59 pm ⇧

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 17, '12 at 12:15a
activeNov 26, '12 at 4:59p
posts8
users4
websitepuppetlabs.com

4 users in discussion

Forrie: 3 posts Jcbollinger: 3 posts Steven Nemetz: 1 post Matthaus Owens: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase