Resource tips and examples: Service
Puppet can manage services on nearly all operating systems.
Most Linux and *nix systems
Normal operation
If your OS 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:
service { 'apache2':
ensure => running,
enable => true,
}
(Note that some operating systems don’t support the enable attribute.)
Defective init script
On platforms that use SysV-style init scripts, Puppet assumes the script will have working start, stop, and status commands.
If the status command is missing, you will need to set hasstatus => false for that service. This will make 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 Red Hat’s 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, you’ll need to set hasstatus => false and also specify either the status or pattern attribute.
No init script or service config
service { 'apache2':
ensure => running,
start => '/usr/sbin/apachectl start',
stop => '/usr/sbin/apachectl stop',
pattern => '/usr/sbin/httpd',
}
If some of your services lack init scripts, Puppet can compensate.
In addition to ensure, you’ll need to specify several additional attributes. Puppet needs to know 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 will also give you default behavior for stopping and status.
Stop
If you specified binary, Puppet will default to finding that same executable in the process table and killing it.
If the service should be stopped some other way, use the stop attribute to specify a command.
Status
If you specified binary, Puppet will default to checking for that executable in the process table; if it doesn’t find it, it assumes 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.
macOS and OS X
macOS and OS X handle services much like most Linuxes; 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.
Also, note that the launchd plists that configure your services must be in one of the following four 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 Linux.
Windows
On Microsoft Windows, Puppet can start, stop, enable, disable, list, query and configure services. It expects that all services will run via Windows’ built-in Service Control Manager (SCM) system. It does not support configuring service dependencies, 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 asAutomatic Updates). - Setting
enable => truewill assign a service the “Automatic” startup type; settingenable => manualwill assign the “Manual” startup type.
A complete service resource is very simple:
service { 'mysql':
ensure => 'running',
enable => true,
}