A strange behavior

If you use a Saltstack minion on a Debian 8 (Jessie), you may have encountered a strange behavior when it comes to services.
As you know (of course, no one can ignore the systemd war on Debian), systemd is now the default service manager on Debian. Well, it's much more than a service manager, but the new service management is one of the most visible changes.

The problem is that some services managed by a state are always re-enabled, even if they were already enabled.
For example, with supervisor :

	ID: supervisor
	Function: service.running
	Result: True
	Comment: Service supervisor has been enabled, and is in the desired state
	Started: 18:35:32.089750
	Duration: 617.27 ms

The next run will yield the exact same result. Which is highly annoying if you run highstate on 20 nodes and need to read quickly the results. It's a noise.

But, why ?

For some reasons, Debian still support SysVinit scripts. There is a layer between systemd and Sysvinit scripts so systemd can (almost) manage daemons who don't have a systemd service file, old SysVinit scripts. When I say almost, I mean it : you can start, restart, reload, status, enable and disable a SysVinit scripted daemon via systemd cli tools. For example, with supervisor :

root@cs-qa-rbx-ovh-pcc-prev-aaa:~# systemctl status supervisor
● supervisor.service - LSB: Start/stop supervisor
  Loaded: loaded (/etc/init.d/supervisor)
  Active: active (running) since Sat 2015-05-16 01:32:28 CEST; 2 days ago
  Process: 7155 ExecStop=/etc/init.d/supervisor stop (code=exited, status=0/SUCCESS)
  Process: 7229 ExecStart=/etc/init.d/supervisor start (code=exited, status=0/SUCCESS)

There is only one missing information, that you can see on a true systemd service, like sshd :

root@lxcserver-a:~# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
  Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
  Active: active (running) since Sun 2015-04-26 21:10:03 CEST; 3 weeks 1 days ago
  Main PID: 550 (sshd)

the enabled status.
Because of that, Saltstack have no way to know if a SysVinit scripted daemon is enabled or not, so it enables it at each run.

A simple solution

With Saltstack, you can specify for each service how it will be managed, with the provider parameter. The provider named debian_service will use standard SysVinit scripts to manage the service, and will fix our problem.

  pkg.installed: []
	- enable: True
	- provider: debian_service

Of course, if you have other distributions than Debian, use some Jinja magic to define a sensible provider =)
You may now enjoy your highstates runs without noise !