Re: Re: Bug#741930: reportbug: add current init system information
Sandro Tosi:
what is the recommended way to identify sysvinit? from the info
> provided above one requires to check a dir existence and the
> checking a command and then execute it to parse its output. it seems
> a bit fragile, and maybe only upstart check really the running
> processes
There isn't really a reliable way to identify any of these as the
current running system, and upstart is not checking the running
processes either.
* To check for systemd as the running system manager in the
"official" manner, one checks for the existence of /run/systemd/system
. This is a directory, in /run, that systemd itself creates at boot,
and that other system managers are unlikely to create. The downside is
that this check will be fooled if ever someone comes along and
implements a system that creates these directories for compatibility
with things that create systemd service units in /run. I suspect that
that already is the case for "uselessd" and this test is already broken.
* To check for upstart as the running system manager, one checks that
there's an initctl command and that the output of "initctl version"
contains the name "upstart" somewhere. There do exist other initctl
commands, aside from the one that comes with Upstart. But they don't
emit the word "upstart".
root ~ #initctl version
nosh version 1.10
root ~ #
Again, the downside is that this is not checking what's running.
In particular, it fails when one has installed Upstart but not yet
rebooted in order to run it.
* To check for the nosh system-manager, one can do the same "initctl
version" test as with upstart, and look for "nosh". Or one can look for
the /run/system-manager directory. Both share the weaknesses of the
equivalent upstart and systemd checks. initctl isn't present as a
command unless one has installed the nosh upstart compatibility shims
package, and there's no guarantee that another initctl won't emit that
string any more that there's a guarantee that a non-upstart initctl
won't emit the string "upstart". And, although there's vanishingly
small reason to do so, it is possible that something else might create a
lookalike /run/system-manager directory. "system-control version" is
the identical command to "initctl version", however, and that is part of
the system management package and not a shim. But on the gripping hand
this is still a test of the software that is installed and ready to run,
not of what is currently running.
* Ironically, and as people are belatedly discovering, one test for
System 5 init installed, that is peculiar to Debian, is that no other
system manager expects the existence of, and no other system management
toolset Debian package has, the file /etc/inittab . Again, this is not a
test for System 5 init running.
To check for what system manager is running right now, as opposed to
what is installed and ready to run, one really has to look at the
process list or at the various APIs that system managers publish. But
this isn't wholly without pitfalls.
* You've already mentioned the problems with /proc/1/exe .
* systemd publishes a whole RPC API over D-Bus, which even contains a
version name and number; but (a) this isn't covered by the infamous
"Interface Stability Guarantee" and could change tomorrow or at whim,
and (b) so too does the lookalike D-Bus server in systemd-shim.
* The existence of /run/systemd/private is similarly not guaranteed.
* The nosh system-manager doesn't create pipes or sockets in the
filesystem, and doesn't have an RPC API in the first place.
* The nosh service-manager conventionally has an API socket at
/run/service-manager/control, but one can run the nosh service manager
under some other system manager; so this doesn't tell one what system
manager is running as process #1. In any case, it doesn't set that name
itself; whatever invoked it does.
* The existence of the control API file /dev/initctl isn't specific
to System 5 init. systemd has a (non process #1) systemd-initctl server
that serves this.
Reply to: