salt-minion not started after installation

This bug was originally filed in Launchpad as [LP: #1804809](https://bugs.launchpad.net/cloud-init/+bug/1804809)

Launchpad details

affected_projects = []

assignee = None

assignee_name = None

date_closed = None

date_created = 2018-11-23T11:44:31.221506+00:00

date_fix_committed = None

date_fix_released = None

id = 1804809

importance = low

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1804809

milestone = None

owner = gilles-dartiguelongue

owner_name = Gilles Dartiguelongue

private = False

status = triaged

submitter = gilles-dartiguelongue

submitter_name = Gilles Dartiguelongue

tags = []

duplicates = []

_Launchpad user **Gilles Dartiguelongue(gilles-dartiguelongue)** wrote on 2018-11-23T11:44:31.221506+00:00_

the cc_salt_minion.py module uses the service command to start salt-minion after installation. However this command is not guaranteed to exist on all distributions.

In Gentoo, openrc stopped providing this binary not so long ago [1] but using systemd on Gentoo does not provide this either. In debian 9 the bin is provided by init-system-helpers [2] which is an essential package meaning removing it most likely breaks your system.

I wanted to suggest to use distro class init_cmd but even this feels a bit limited as it requires duplication for distributions that support more than one init system. Would it make sense to create a class hierarchy to support the classical init systems out there (openrc, debian-style init, systemd) and allow automatic detection of the actual init being used ?

[1] https://www.gentoo.org/support/news-items/2017-10-13-openrc-service-binary-removal.html
[2] https://packages.debian.org/unstable/main/init-system-helpers