[systemd-devel] [RFC] the chopping block

[Lennart Poettering]

On Thu, 18.02.16 20:33, Mike Gilbert (floppym at gentoo.org) wrote:

> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
> >    time Debian was still using that, maybe this changed now?
> 
> Gentoo allows switching between systemd and openrc (sysvinit) at boot
> time, and will continue to do so for the foreseeable future.
> 
> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
> swap these to symlinks to systemd and systemctl by setting a USE flag,
> but if they do so they knowingly lose the ability to switch back to
> openrc without a rebuild of the affected packages.
> 
> I would like to selfishly request that you keep this interface around
> as long as possible; if you remove it I will have to come up with some
> replacement.

So here's probably what is going to happen.

The initctl support in systemctl will be dropped and replaced by some
callout script support. i.e. when you want to use systemctl to reboot
a sysvinit system, then systemctl won't do that anymore, but it will
invoke some shell script as a fallback, where distros can place the
necessary commands if they care about this. This follows how we do
sysv script enable/disable handling (i.e. the chkconfig hookup).

We'll eventually kill /dev/initctl support. Distros should really find
their own replacement for this. They can either take the current code,
build it externally, or write some new code. You might be able to
implement this in a carefully prepared shell script that invokes
busctl to do the reboot. You could use "dd" to read the initreq
structure from STDIN with the precise size, then figure out which kind
of request it is (again, by using dd to extract the four bytes
starting at index 4 of that request structure) and then simply execute
the right busctl command to poweroff/reboot/...

I'll not drop this right-away, but let's say in 6month or so this will
go away. This should be an ample heads-up to find a replacement and
prepare for this.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat