This is also wrong -- /sbin/init is different depending on whether you have systemd-sysv or upstart-sysv installed, so checking /proc/cmdline for /sbin/init doesn't tell you anything. Checking for /run/systemd/system is the correct, reliable, and fast thing to do here indeed.
@xnox As noted in my last comment, we have to be able to run this on arbitrary remote systems, both via ssh and a cloud-init script. So using a bash script was our best option. We also needed to be confident about the running init system, which is what checking PID 1 accomplishes perfectly.
@martinpitt We no longer assume /sbin/init implies upstart.
It's a predictable file name in a world-writable directory. So any user can destroy any file in the system (also from other users, or from root) by e. g. ln -s /etc/shadow /tmp/discover_init_system.sh and then wait for juju to run. (google for /tmp overwrite race, there have been plenty of CVEs in the past). So if you create/call a shell script, please use mktemp.
But I'm still convinced that this is overkill. You can check what's running on a remote system with a single shell command (testing for /run/systemd/system and/or for initctl --system list).
While that works for the local host, for interacting with remote hosts it isn't an option. We went with a bash script in that case for the confidence that it will work effectively universally. If you know of a better approach that can be used over ssh on arbitrary hosts (as well as in a cloud-init script) then please let us know.
As to the commands for deciding the init system, we went with using the executable running in PID 1 because the approach gives better information in the case that we don't recognize the init system. Furthermore, the only way to be absolutely sure about the running init system is by checking PID 1. Beyond that, we wanted to bake into juju as little knowledge of each init system as possible. The directory that the init system uses is an example of that.
I cringe reading this =)
[ -d /run/systemd/systemd ] -> system is running PID 1 as systemd. You can check that in go code natively, without forking out to a shell.
check that system is running upstart can be done with