Using service

Puppet can manage services on nearly all operating systems.This page offers operating system-specific advice and best practices for working with service.

Using service on *nix systems

If your *nix operating system has a good system for managing services, and all the services you care about have working init scripts or service configs, you can write small service resources with just the ensure and enable attributes.

For example:
service { 'apache2':
  ensure => running,
  enable => true,
}
Note: Some *nix operating systems don't support the enable attribute.

Defective init script

On platforms that use SysV-style init scripts, Puppet assumes the script has working start, stop, and status commands. See descriptions below.

If the status command is missing, set hasstatus => false for that service. This makes Puppet search the process table for the service’s name to check whether it’s running.

In some rare cases — such as virtual services like the Red Hat network — a service won’t have a matching entry in the process table. If a service acts like this and is also missing a status command, set hasstatus => false and also specify either status or pattern attribute.

No init script or service config

If some of your services lack init scripts, Puppet can compensate, as in the following example:
service { "apache2":
  ensure  => running,
  start   => "/usr/sbin/apachectl start",
  stop    => "/usr/sbin/apachectl stop",
  pattern => "/usr/sbin/httpd",
}
In addition to specifing ensure, specify also how to start the service, how to stop it, how to check whether it’s running, and optionally how to restart it.
Start

Use either start or binary to specify a start command. The difference is that binary also gives you default behavior for stop and status.

Stop

If you specified binary, Puppet defaults to finding that same executable in the process table and killing it.

To stop the service some other way, use the stop attribute to specify the appropriate command.

Status

If you specified binary, Puppet checks for that executable in the process table. If it doesn’t find it, it reports that the service isn’t running.

If there’s a better way to check the service’s status, or if the start command is just a script and a different process implements the service itself, use either status (a command that exits 0 if the service is running and nonzero otherwise) or pattern (a pattern to search the process table for).

Restart
If a service needs to be reloaded, Puppet defaults to stopping it and starting it again. If you have a safer command for restarting a service, you can optionally specify it in the restart attribute.

Using service on macOS

macOS handles services much like most *nix-based systems. The main difference is that enable and ensure are much more closely linked — running services are always enabled, and stopped ones are always disabled.

For best results, either leave enable blank or make sure it’s set to true whenever ensure => running.

The launchd plists that configure your services must be in one of the following directories:

  • /System/Library/LaunchDaemons

  • /System/Library/LaunchAgents

  • /Library/LaunchDaemons

  • /Library/LaunchAgents

You can also specify start and stop commands to assemble your own services, much like on *nix systems.

Using service on Windows

On Windows, Puppet can start, stop, enable, disable, list, query, and configure services. It expects that all services run with the built-in Service Control Manager (SCM) system. It does not support configuring service dependencies, the account to run as, or desktop interaction.

When writing service resources for Windows, remember the following:

  • Use the short service name (such as wuauserv) in Puppet, not the display name (such as Automatic Updates).

  • Set enable => true to assign a service the Automatic startup type.

  • Set enable => manual to assign the Manual startup type.

For example, here is a complete service resource:
service { 'mysql':
  ensure => 'running',
  enable => true,
}
Puppet 7 adds support for managing the logon user and password to the Windows service provider. For example:
service { 'name-of-service':
  ensure              => 'running',
  enable              => 'true', 
  logonaccount   => 'domain\\user', 
  logonpassword => $password,
}

Note that the logonpassword is a sensitive variable.

Managing systemd services

In addition to the default values for the ensure and enable attributes, you can mask systemd services by setting enable => mask.

Note that static services can not be enabled by design, and services of type indirect can not be enabled due to a limitation in the implementation of systemd. When restarting services, Puppet checks whether any unit files were modified and runs daemon-reload when required.