When a service resource has the attribute ensure => running attribute, Puppet needs to be able to check whether the service is, in fact, running. The way it does this depends on the underlying operating system. On Ubuntu 16 and later, for example, it runs systemctl is-active SERVICE. If the service is packaged to work with systemd, that should be just fine, but in many cases, particularly with older software, it may not respond properly.

If you find that Puppet keeps attempting to start the service on every Puppet run, even though the service is running, it may be that Puppet's default service status detection isn't working. In this case, you can specify the hasstatus => false attribute for the service (service_hasstatus.pp):

service { 'ntp':
  ensure    => running,
  enable    => true,
  hasstatus => false,
}

When hasstatus is false, Puppet knows not to try to check the service status using the default system service management command, and instead, will look in the process table for a running process which matches the name of the service. If it finds one, it will infer that the service is running and take no further action.

Sometimes, when using hasstatus => false, the service name as defined in Puppet doesn't actually appear in the process table, because the command that provides the service has a different name. If this is the case, you can tell Puppet exactly what to look for using the pattern attribute.

If hasstatus is false and pattern is specified, Puppet will search for the value of pattern in the process table to determine whether or not the service is running. To find the pattern you need, you can use the ps command to see the list of running processes:

ps ax

Find the process you're interested in and pick a string which will match only the name of that process. For example, if it's ntpd, you might specify the pattern attribute as ntpd (service_pattern.pp):

service { 'ntp':
  ensure    => running,
  enable    => true,
  hasstatus => false,
  pattern   => 'ntpd',
}

When a service is notified (for example, if a file resource uses the notify attribute to tell the service its config file has changed, a common pattern which we looked at in Chapter 2, Creating your first manifests), Puppet's default behavior is to stop the service, then start it again. This usually works, but many services implement a restart command in their management scripts. If this is available, it's usually a good idea to use it: it may be faster or safer than stopping and starting the service. Some services take a while to shut down properly when stopped, for example, and Puppet may not wait long enough before trying to restart them, so that you end up with the service not running at all.

If you specify hasrestart => true for a service, then Puppet will try to send a restart command to it, using whatever service management command is appropriate for the current platform (systemctl, for example, on Ubuntu). The following example shows the use of hasrestart (service_hasrestart.pp):

service { 'ntp':
  ensure     => running,
  enable     => true,
  hasrestart => true,
}

To further complicate things, the default system service restart command may not work, or you may need to take certain special actions when the service is restarted (disabling monitoring notifications, for example). You can specify any restart command you like for the service using the restart attribute (service_custom_restart.pp):

service { 'ntp':
  ensure  => running,
  enable  => true,
  restart => '/bin/echo Restarting >>/tmp/debug.log && systemctl restart ntp',
}

In this example, the restart command writes a message to a log file before restarting the service in the usual way, but it could, of course, do anything you need it to. Note that the restart command is only used when Puppet restarts the service (generally because it was notified by a change to some config file). It's not used when starting the service from a stopped state. If Puppet finds the service has stopped and needs to start it, it will use the normal system service start command.

In the extremely rare event that the service cannot be stopped or started using the default service management command, Puppet also provides the stop and start attributes so that you can specify custom commands to stop and start the service, just the same way as with the restart attribute. If you need to use either of these, though, it's probably safe to say that you're having a bad day.