puppet notify xinetd doesn't reload xinetd service

Question

I’m trying to install check_mk agent with the standard check_mk xinetd config file via puppet on a Debian 7 server.

Check_mk installs without a problem but I've got an issue with the xinetd config.

When I change the port in the source config file on the puppet master and run puppet agent -t on the client host the new configuration is deployed correctly but puppet doesn't reload the xinetd service because the system can't recognize the state of the xinetd service.

The puppet manifest looks like this:

    class basic::check-mk {
case $operatingsystem {
  debian: {
         package {'check-mk-agent':
                 ensure => present,
                 }

         file    { '/etc/xinetd.d/check_mk':
                 notify => Service['xinetd'],
                 ensure => file,
                 source => 'puppet:///modules/basic/etc--xinetd--checkmk',
                 mode   => '0644',
                 }

         service { 'xinetd':
                 ensure  => running,
                 enable  => true,
                 restart => '/etc/init.d/xinetd reload',
                 }
          }
 }
}

The debug looks like this:

    info: Applying configuration version '1464186485'
debug: /Stage[main]/Ntp::Config/notify: subscribes to Class[Ntp::Service]
debug: /Stage[main]/Ntp/Anchor[ntp::begin]/before: requires Class[Ntp::Install]
debug: /Stage[main]/basic::Check-mk/Service[xinetd]/subscribe: subscribes to File[/etc/xinetd.d/check_mk]
debug: /Stage[main]/Ntp::Install/before: requires Class[Ntp::Config]
debug: /Stage[main]/Ntp::Service/before: requires Anchor[ntp::end]
debug: /Schedule[daily]: Skipping device resources because running on a host
debug: /Schedule[monthly]: Skipping device resources because running on a host
debug: /Schedule[hourly]: Skipping device resources because running on a host
debug: Prefetching apt resources for package
debug: Executing '/usr/bin/dpkg-query -W --showformat '${Status} ${Package} ${Version}\n''
debug: Puppet::Type::Package::ProviderApt: Executing '/usr/bin/dpkg-query -W --showformat '${Status} ${Package} ${Version}\n''
debug: /Schedule[never]: Skipping device resources because running on a host
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]/content: Executing 'diff -u /etc/xinetd.d/check_mk /tmp/puppet-file20160525-10084-1vrr8zf-0'
notice: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]/content:
--- /etc/xinetd.d/check_mk      2016-05-25 14:57:26.220873468 +0200
+++ /tmp/puppet-file20160525-10084-1vrr8zf-0    2016-05-25 16:28:06.393363702 +0200
@@ -25,7 +25,7 @@
 service check_mk
 {
         type           = UNLISTED
-        port           = 6556
+        port           = 6554
         socket_type    = stream
         protocol       = tcp
         wait           = no

debug: Finishing transaction 70294357735140
info: FileBucket got a duplicate file {md5}cb0264ad1863ee2b3749bd3621cdbdd0
info: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]: Filebucketed /etc/xinetd.d/check_mk to puppet with sum cb0264ad1863ee2b3749bd3621cdbdd0
notice: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]/content: content changed '{md5}cb0264ad1863ee2b3749bd3621cdbdd0' to '{md5}56ac5c1a50c298de4999649b27ef6277'
debug: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]: The container Class[basic::Check-mk] will propagate my refresh event
info: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]: Scheduling refresh of Service[xinetd]
debug: Service[ntp](provider=debian): Executing '/etc/init.d/ntp status'
debug: Service[xinetd](provider=debian): Executing '/etc/init.d/xinetd status'
debug: Service[xinetd](provider=debian): Executing '/etc/init.d/xinetd start'
notice: /Stage[main]/basic::Check-mk/Service[xinetd]/ensure: ensure changed 'stopped' to 'running'
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: The container Class[basic::Check-mk] will propagate my refresh event
debug: Service[xinetd](provider=debian): Executing '/etc/init.d/xinetd status'
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: Skipping restart; service is not running
notice: /Stage[main]/basic::Check-mk/Service[xinetd]: Triggered 'refresh' from 1 events
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: The container Class[basic::Check-mk] will propagate my refresh event
debug: Class[basic::Check-mk]: The container Stage[main] will propagate my refresh event
debug: /Schedule[weekly]: Skipping device resources because running on a host
debug: /Schedule[puppet]: Skipping device resources because running on a host
debug: Finishing transaction 70294346109840
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 1.43 seconds
debug: Executing '/etc/puppet/etckeeper-commit-post'
debug: report supports formats: b64_zlib_yaml pson raw yaml; using pson

The following line seems suspicious to me:

debug: /Stage[main]/basic::Check-mk/Service[xinetd]: Skipping restart; service is not running

And service --status-all says [ ? ] xinetd. Why does the system not recognize the state of the service?

Have you tried changing the `notify` from the `file` resource to a `subscribe` from the `service` resource? Should not change anything, but it might. The `restart` command might also be at fault here. Puppet usually expects the full command and not an abbreviated one (e.g. `/bin/sh script.sh` and not just `script.sh`) — Matthew Schuchard, May 25 '16 at 11:20
I changed the manifest from `notify` to `subscribe`. I also removed the `restart` line. Bit it didn't change anything. — elcaos, May 25 '16 at 14:44
@elcaos, the debug log is not an answer. Edit it into your question. — John Bollinger, May 25 '16 at 15:41
It is unlikely to be the source of your problem, but the hypen (`-`) is not among [the characters allowed in class and defined-type names](https://docs.puppet.com/puppet/4.5/reference/lang_reserved.html#classes-and-defined-resource-types). Your ancient Puppet appears not to be complaining, but before they were explicitly banned, hyphens appearing in names caused issues in some places. — John Bollinger, May 25 '16 at 15:47
I did not mean removing the `restart` attribute, but rather that it may be faulty. — Matthew Schuchard, May 25 '16 at 17:00
@John Bollinger, thanks very much for your help. Stackoverflow is new to me. — elcaos, May 26 '16 at 09:27
@Matt Schuchard, Hi Matt, I tryed it both ways. Removing the whole line and changing it to `/bin/bash...`, `service ...` and so on. — elcaos, May 26 '16 at 09:31

score 2 · Accepted Answer · answered May 25 '16 at 16:12

2

Your debug log and the output of your manual service command suggest that your xinetd does not have a working status subcommand. As a result, Puppet does not know how (or whether) to manage its run state.

You could consider fixing the initscript to recognize the status subcommand and make an LSB-compliant response (or at least to exit with code 0 if the service is running and anything else otherwise). Alternatively, you can add a status attribute to the Service resource, giving an alternative command that Puppet can use to ascertain the service's run state. (I have linked to the current docs, but I'm pretty sure that Service has had that attribute since well before Puppet 2.7.)

answered May 25 '16 at 16:12

John Bollinger

160,171
8
81
157

This is likely the correct path forward. Also, the debug log shows the `notify` is working correctly so the question needs to be edited to reflect what the real problem is here. – Matthew Schuchard May 25 '16 at 17:04
This seems to be the solution. I will try this tomorrow and reply. Thanks very much. – elcaos May 26 '16 at 12:51
@John Bollinger, this was the right answer. My xinetd init.d script was missing a status passage. I added it and puppet is reloading the service as it's supposed to do. Can I add the script configuration in my question or as an answer so others can use it? – elcaos May 26 '16 at 14:46
@elcaos, if you want to provide the modification you made to your initscript, then that would be better done as part of an answer than as an edit to your question. Include also some explanatory text, such as the first part of your comment about it, so that it stands on its own as an answer in its own right. – John Bollinger May 26 '16 at 14:58

score 1 · Answer 2 · answered May 26 '16 at 15:40

SOLVED: To fix the problem I had to add a status section to the init.d script of xinetd. Afterwards service xinetd status and puppet were able to recognize the status of the service. The added section looks like this:

status)
    if pidof xinetd > /dev/null
    then
      echo "xinetd is running."
      exit 0
    else
      echo "xinetd is NOT running."
      exit 1
    fi
;;

Additionaly I added the status option to the Usage line:

    *)
    echo "Usage: /etc/init.d/xinetd {start|stop|reload|force-reload|restart|status}"
    exit 1
    ;;

This solved the problem.

puppet notify xinetd doesn't reload xinetd service

2 Answers2