[systemd-devel] RFC: removing initctl support

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 12:32:25PM +0200, Lennart Poettering wrote:
> On Tue, 22.09.15 10:11, Daniel P. Berrange (berrange at redhat.com) wrote:
> 
> > > And most importantly: the entire protocol use by sysvinit via
> > > /dev/initctl is deeply flawed, since it sends messages over
> > > /dev/initctl that are not a divisor of PIPE_SIZE in length. Thus, if
> > > PID 1 didn't read messages quick enough the messages queued could be
> > > half-written and be partially interleaved with another client's
> > > messages, and there is no way the system can ever recover from that.
> > > 
> > > Thus, I'd really like to kill this. Does anybody care about it, and
> > > can give me a strong enough reason to keep this anyway?
> > 
> > The libvirt virDomainShutdown|Reboot APIs for triggering controlled
> > shutdown/reboots of guest OS have support for using /dev/initctl with
> > containers, as it was the lowest common denominator that easily worked
> > across systemd, sysvinit & upstart.
> 
> Ah, I see... But I wasn't aware Upstart even implemented that...

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.

> > We could add further code to use a systemd specific interface if
> > needed, so it wouldn't be the end of the world of /dev/initctl was
> > removed, but it'd be nice to not have todo that.
> 
> A simple fall back could be to send SIGRTMIN+4 to PID 1, if
> /dev/initctl is not around.

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 :-)

> One more addendum to the original mail:
> 
> We already declared the interface "obsolete" in the docs, which makes
> me particularly keen on dropping it...

I guess one thing is that even if support for /dev/intctl in systemd,
it is an optional unit file, so libvirt probably needs to deal with
the SIGRTMIN+4 stuff anyway, for case where the person building
the container has that unit file disabled. So from that POV, deleting
it won't make current situation that much worse.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|