[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: