[systemd-devel] RFC: removing initctl support

Jonathan de Boyne Pollard j.deboynepollard-newsgroups at ntlworld.com
Thu Sep 24 05:18:17 PDT 2015


Daniel P. Berrange:
> Maybe it wasn't actually upstart, but one of the other init systems.
> I just recall getting a patch from Debian folks to support it via
> the /run/initctl path, rather than /dev, and assumed that was upstart
> related.

It wasn't upstart or one of the other init systems.  It was the System 5 init
(clone) people deciding to move the FIFO into /run in response to a bug report
against it.  Their position, exemplified at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657990#57 , was that it was
their private non-SVID interface that they weren't expecting anyone to use
directly and that they could do that at whim. See
http://superuser.com/a/888936/38062 for more of the story.

Lennart Poettering:
> A simple fall back could be to send SIGRTMIN+4 to PID 1, if
> /dev/initctl is not around.

Daniel P. Berrange: 
> Yep, though we'd have to actually check that PID 1 is systemd, since
> if you run a container with a non-init program as PID 1, we don't
> want to be sending it SIGRTMIN+4 :-)

In an ideal world you would be able to have a routine that detected the running
system manager, and then did whatever was appropriate to that system manager to
power off, from sending signals to process #1 through running the System 5
init/rc clone's "shutdown -h -P now" command to sending requests to upstart's
Desktop Bus API.  In the real world, all of the problems that make detecting the
running system manager really difficult to do that are described at
http://unix.stackexchange.com/a/196252/5132 rear their ugly heads.  (A further
problem not mentioned there: Joachim Nilsson's finit also responds to "initctl
version".)


More information about the systemd-devel mailing list