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".) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
