Why not go one step further and separate this into different modules,
like with the package management modules? When using the service
module I was asking myself if it was designed to work with various
Linux distributions (it did work in my case). Separate modules would
make that more obvious...
It actually has been designed to work with various Linux (and BSDish) distributions and I guess the reason for this is easier scalability as one does not have to distinguish between the host operating systems in the playbooks.
In general, I prefer your solution of separate modules for each way of managing services but this has several implications for administering heterogeneous environments. For example, systemd’s ‘systemctl’ tool supports enabling/disabling a service as well as controlling it (start/stop/reload/restart) while on many distributions, the enable/disable part is done by one tool (‘update-rc.d’, ‘chkconfig’, etc.) and controlling by another (‘initctl’, ‘service’ or by just calling the script from /etc/init.d directly). So in the end, the separate modules would merely be command wrappers…
I think it’s best to check inside the service module which service-management solution is available on the host (i.e. systemctl, chkconfig/service etc.) but to be honest, I don’t like the way it’s done at the moment (lots of if-statements to build up the correct command line). I’ll give some more thought to it over the weekend and hope to come up with a satisfying solution.