[Reportbug-maint] Bug#741930: Re: Bug#741930: reportbug: add current init system information

[Jonathan de Boyne Pollard]

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.