Architecture #3828
closed
Adapt Techniques so they use available init system on each Node
Description
This applies to servicesManagement technique as well as other techniques that internally start/stop/restart services (e.g. cronManagement, nfsServer, sshConfiguration, clockConfiguration, apacheServer, system/common, etc.).
Specifically, it is assumed that /etc/init.d/$SERVICE script can be used to control the service, which is not always true.
The /etc/init.d script method won't work if the service isn't a sysv service but e.g. an upstart job. So far this hasn't been causing many issues as upstart is mainly used on ubuntu where packages redirect their /etc/init.d/$SERVICE to call appropriate upstart command. However support for upstart jobs is being slowly merged into Debian and since Ubuntu Saucy calling /etc/init.d/$SERVICE for a service managed by upstart will be an error. In fact Debian policy recommends using "service" script (or "invoke-rc.d" - for maintainer scripts) which abstracts the differences and handles calling the correct command internally.
See https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html
Using the "service" script would seem like a better option. Still there are two problems: on RedHat/CentOS the script doesn't actually handle upstart jobs (this is an upstream issue though, I think I'll report it there), and the script location needs to be abstracted (it's in /sbin/service on RHEL/CentOS and in /usr/sbin/service on Debian/Ubuntu).
What do you think?
Updated by 
Updated by 
Updated by Matthieu CERDA 
Updated by Jonathan CLARKE