[systemd-devel] RFC: removing initctl support

[e-mail j.deboynepollard-newsgroups]

Lennart Poettering:
> We already declared the interface "obsolete" in the docs, which makes me
> particularly keen on dropping it...

You've heard from the Debian systemd maintainers. You haven't heard from
the Debian sysvinit maintainers. Their subtly different position on
/run/initctl, exemplified by Roger Leigh (one of those maintainers) writing in
2012, is this:

> The protocol is private and undocumented, so there should be
> no third-party users. The location is hard-coded directly into the
> binaries and is likely only intended to be used by sysvinit
> binaries. systemd is an exception to this rule, and I would
> suspect the only one.
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657990#57

M. Leigh's suspicion is wrong today, however. The nosh package and Joachim
Nilsson's finit both also have compatibility shims that listen on /dev/initctl
or /run/initctl .  See http://superuser.com/a/888936/38062 for more information.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Martin Pitt]

Hello all,

sorry for the late reply, I've been swamped with other stuff recently.

Lennart Poettering [2015-09-22  2:31 +0200]:
> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".

We indeed need this for upgrades: If you e. g. install Ubuntu 14.04
LTS (with upstart), or Debian Jessie (with SysV init) and install the
systemd packages during the upgrade, you need to be able to reboot
into the upgraded system (while upstart/sysvinit is still running). So
indeed it's only needed exactly once, but we need to keep this around
until at least April 2016 when Ubuntu 16.04 LTS will release (and then
we can reasonably assume that systemd will be running for any further
upgrades).

On Debian it's much harder to give a precise time line as the official
project decision is still to support multiple init systems. But if
there's a documented workaround, that'd also suffice.

> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.

This direction seems much less important to me -- you can always call
"systemctl reboot" while systemd is pid 1, no?

> We never even really used this stuff on Fedora properly (since we
> actually transitioned from Upstart, not sysvinit, and we never had the
> same level of compat for that...).

You should run into the same problem if you upgrade an upstart system
to systemd, no? You can't possibly exec systemd over upstart in a
running system.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Thu, 24.09.15 13:18, Jonathan de Boyne Pollard 
(j.deboynepollard-newsgro...@ntlworld.com) wrote:

> 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".)

That stackexchange link lists a pile of garbage. We have an official
API to check whether the system is booted with systemd:
sd_booted(). It's documented here:

http://www.freedesktop.org/software/systemd/man/sd_booted.html

And we even document on that man page what precisely it does
internally (which is equivalent to access("/run/systemd/system/",
F_OK) >= 0) and suggest people to reimplement that simple check in the
language of their choice, even in shell... That way, they don't even
have to link against libsystemd.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] RFC: removing initctl support

[Jonathan de Boyne Pollard]

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

Re: [systemd-devel] RFC: removing initctl support

[Tomasz Torcz]

On Thu, Sep 24, 2015 at 03:01:21PM +0200, Lennart Poettering wrote:
> That stackexchange link lists a pile of garbage. We have an official
> API to check whether the system is booted with systemd:
> sd_booted(). It's documented here:
> 
> http://www.freedesktop.org/software/systemd/man/sd_booted.html
> 
> And we even document on that man page what precisely it does
> internally (which is equivalent to access("/run/systemd/system/",
> F_OK) >= 0) and suggest people to reimplement that simple check in the
> language of their choice, even in shell... That way, they don't even
> have to link against libsystemd.

  And then there is this sabotage:

„This check is already broken, because uselessd creates this directory too”

uselessd% git grep 'mkdir.*/run/systemd/system'
src/core/main-no-init.c:mkdir_label("/run/systemd/system", 0755);
src/core/mount-setup.c:mkdir_label("/run/systemd/system", 0755);
src/core/unit.c:mkdir_p("/run/systemd/system", 0755);

  Meh.

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Thu, 24.09.15 15:51, Tomasz Torcz (to...@pipebreaker.pl) wrote:

> On Thu, Sep 24, 2015 at 03:01:21PM +0200, Lennart Poettering wrote:
> > That stackexchange link lists a pile of garbage. We have an official
> > API to check whether the system is booted with systemd:
> > sd_booted(). It's documented here:
> > 
> > http://www.freedesktop.org/software/systemd/man/sd_booted.html
> > 
> > And we even document on that man page what precisely it does
> > internally (which is equivalent to access("/run/systemd/system/",
> > F_OK) >= 0) and suggest people to reimplement that simple check in the
> > language of their choice, even in shell... That way, they don't even
> > have to link against libsystemd.
> 
>   And then there is this sabotage:
> 
> „This check is already broken, because uselessd creates this directory too”
> 
> uselessd% git grep 'mkdir.*/run/systemd/system'
> src/core/main-no-init.c:mkdir_label("/run/systemd/system", 0755);
> src/core/mount-setup.c:mkdir_label("/run/systemd/system", 0755);
> src/core/unit.c:mkdir_p("/run/systemd/system", 0755);
> 
>   Meh.

Why would anyone care? It's not that anyone was actually using
this... Also, by doing this, that software explicitls *wants* to be
treated like systemd, hence why not let it?

If people focus on weird init systems like that, that's certainly
their own fault...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Daniel P. Berrange]

On Thu, Sep 24, 2015 at 03:51:16PM +0200, Tomasz Torcz wrote:
> On Thu, Sep 24, 2015 at 03:01:21PM +0200, Lennart Poettering wrote:
> > That stackexchange link lists a pile of garbage. We have an official
> > API to check whether the system is booted with systemd:
> > sd_booted(). It's documented here:
> > 
> > http://www.freedesktop.org/software/systemd/man/sd_booted.html
> > 
> > And we even document on that man page what precisely it does
> > internally (which is equivalent to access("/run/systemd/system/",
> > F_OK) >= 0) and suggest people to reimplement that simple check in the
> > language of their choice, even in shell... That way, they don't even
> > have to link against libsystemd.
> 
>   And then there is this sabotage:
> 
> „This check is already broken, because uselessd creates this directory too”
> 
> uselessd% git grep 'mkdir.*/run/systemd/system'
> src/core/main-no-init.c:mkdir_label("/run/systemd/system", 0755);
> src/core/mount-setup.c:mkdir_label("/run/systemd/system", 0755);
> src/core/unit.c:mkdir_p("/run/systemd/system", 0755);

Well if it wants to claim to be systemd, then it is responsible for
providing the same API/ABIs as systemd. IOW it must respond to SIGRTMIN+4
in the same way, etc.


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

Re: [systemd-devel] RFC: removing initctl support

[Mike Gilbert]

On Mon, Sep 21, 2015 at 8:31 PM, Lennart Poettering
 wrote:
> Heya!
>
> Since a long time systemd has been shipping with two-way compat
> support for /dev/initctl, and I am tempted to remove it. Before I do
> so, I'd like some input on the relevance of this interface:

Gentoo currently utilizes this interface by default; our sysvinit
package is installed by default to support OpenRC, and provides the
reboot/poweroff commands.

We do optionally support replacing those commands with symlinks to
systemctl, but there are a few blockers which prevent us from enabling
that configuration by default. We are working on resolving that, but
it may be another year or so at the rate it is currently going.

I would appreciate it if you kept this around for a while longer.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Michael Biebl]

What we could add is a --disable switch which makes
units/systemd-initctl.{socket,service} and src/initctl/ conditional so
distros that don't need it anymore can disable it (or make it disabled
by default and let distros which need it enable it).

Would that work for you, Lennart?

2015-09-23 1:17 GMT+02:00 Michael Biebl :
> 2015-09-23 0:45 GMT+02:00 Lennart Poettering :
>> On Wed, 23.09.15 00:38, Michael Biebl (mbi...@gmail.com) wrote:
>>
>>> Hi,
>>>
>>> yes, in Debian we'll need /dev/initctl support for at least another
>>> release cycle so users can switch between the init system and safely
>>> reboot (in both directions).
>>
>> How does Debian switch between the init systems? Couldn't you just use
>> the right client for the right init system?
>
> Well, you can't replace the running sysvinit instance with systemd
> (and vice versa).
> That's why we need the sysvinit tools to talk to systemd via
> /dev/initctl and the systemd tools to talk to sysvinit.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Michael Biebl]

2015-09-23 0:45 GMT+02:00 Lennart Poettering :
> On Wed, 23.09.15 00:38, Michael Biebl (mbi...@gmail.com) wrote:
>
>> Hi,
>>
>> yes, in Debian we'll need /dev/initctl support for at least another
>> release cycle so users can switch between the init system and safely
>> reboot (in both directions).
>
> How does Debian switch between the init systems? Couldn't you just use
> the right client for the right init system?

Well, you can't replace the running sysvinit instance with systemd
(and vice versa).
That's why we need the sysvinit tools to talk to systemd via
/dev/initctl and the systemd tools to talk to sysvinit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Michael Biebl]

Hi,

yes, in Debian we'll need /dev/initctl support for at least another
release cycle so users can switch between the init system and safely
reboot (in both directions).
If it's not too much of a nuisance, it would be great if it could
still be provided a bit longer upstream, otherwise we'll have to carry
it as a downstream patch.
It don't really think the code is bit-rotting, it's simply mature code
which does what it needs to do.
That said, since we will need in Debian anyway, we can just as well
maintain it upstream.

Lennart, do you have any open issues regarding /dev/initctl? We
(myself and I guess Martin as well), can have a look then.

In summary: Please consider keeping the code and if you need someone
to look after it, then I volunteer.

Michael

2015-09-22 13:49 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> On Tue, Sep 22, 2015 at 02:31:25AM +0200, Lennart Poettering wrote:
>> Heya!
>>
>> Since a long time systemd has been shipping with two-way compat
>> support for /dev/initctl, and I am tempted to remove it. Before I do
>> so, I'd like some input on the relevance of this interface:
> I'd guess that debian might care, as they are trying to keep
> bidirectional compat. Apart from that, meh, probably nobody.
> Let's see what they say.
>
> Zbyszek
>
>> a) there's support in systemctl to reboot the system by sending the
>>right bytes to /dev/initctl as fallback, so that you can reboot a
>>sysvinit system with "systemctl reboot".
>>
>> b) There's a mini-daemon "systemd-initctl.service" that is
>>fifo-activated on /dev/initctl, and forwards reboot requests from
>>old sysvinit clients to systemd.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Wed, 23.09.15 00:38, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
> 
> yes, in Debian we'll need /dev/initctl support for at least another
> release cycle so users can switch between the init system and safely
> reboot (in both directions).

How does Debian switch between the init systems? Couldn't you just use
the right client for the right init system?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 02:31:25AM +0200, Lennart Poettering wrote:
> Heya!
> 
> Since a long time systemd has been shipping with two-way compat
> support for /dev/initctl, and I am tempted to remove it. Before I do
> so, I'd like some input on the relevance of this interface:
> 
> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".
> 
> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.
> 
> Both of this was supposed to help transition between sysvinit and
> systemd systems: if you mix sysvinit clients with a systemd init
> system and vice versa, you can still use the the tools to reboot the
> other system.
> 
> I'd claim the interface is borderline useless: the only operation you
> can actually readlly properly dispatch with it is rebooting, and
> reloading PID1. And that's pretty much it.
> 
> We never even really used this stuff on Fedora properly (since we
> actually transitioned from Upstart, not sysvinit, and we never had the
> same level of compat for that...).
> 
> This code has been bitrotting for a while, and nobody really cared.
> 
> 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.

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.

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

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Tue, 22.09.15 10:11, Daniel P. Berrange (berra...@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...

> 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.

One more addendum to the original mail:

We already declared the interface "obsolete" in the docs, which makes
me particularly keen on dropping it...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 12:48:21PM +0200, Lennart Poettering wrote:
> On Tue, 22.09.15 11:41, Daniel P. Berrange (berra...@redhat.com) wrote:
> 
> > > 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.
> 
> Also, we support builds with all legacy cruft disabled, which is
> something where inictl currently is not disabled, but if we kept it
> should really be disable under... So I figure even if we keep the
> general support in this is not an interface you can rely on...
> 
> To make the SIGRTMIN+4 reliable all you need to do is check first if
> /run/systemd/system/ exists.

Ok, that's easy enough. So no objection from libvirt if you remove
/dev/initctl in future releases


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

Re: [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 (berra...@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 :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Lennart Poettering]

On Tue, 22.09.15 11:41, Daniel P. Berrange (berra...@redhat.com) wrote:

> > 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.

Also, we support builds with all legacy cruft disabled, which is
something where inictl currently is not disabled, but if we kept it
should really be disable under... So I figure even if we keep the
general support in this is not an interface you can rely on...

To make the SIGRTMIN+4 reliable all you need to do is check first if
/run/systemd/system/ exists.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 22, 2015 at 02:31:25AM +0200, Lennart Poettering wrote:
> Heya!
> 
> Since a long time systemd has been shipping with two-way compat
> support for /dev/initctl, and I am tempted to remove it. Before I do
> so, I'd like some input on the relevance of this interface:
I'd guess that debian might care, as they are trying to keep
bidirectional compat. Apart from that, meh, probably nobody.
Let's see what they say.

Zbyszek

> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".
> 
> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] RFC: removing initctl support

[Lennart Poettering]

Heya!

Since a long time systemd has been shipping with two-way compat
support for /dev/initctl, and I am tempted to remove it. Before I do
so, I'd like some input on the relevance of this interface:

a) there's support in systemctl to reboot the system by sending the
   right bytes to /dev/initctl as fallback, so that you can reboot a
   sysvinit system with "systemctl reboot".

b) There's a mini-daemon "systemd-initctl.service" that is
   fifo-activated on /dev/initctl, and forwards reboot requests from
   old sysvinit clients to systemd.

Both of this was supposed to help transition between sysvinit and
systemd systems: if you mix sysvinit clients with a systemd init
system and vice versa, you can still use the the tools to reboot the
other system.

I'd claim the interface is borderline useless: the only operation you
can actually readlly properly dispatch with it is rebooting, and
reloading PID1. And that's pretty much it.

We never even really used this stuff on Fedora properly (since we
actually transitioned from Upstart, not sysvinit, and we never had the
same level of compat for that...).

This code has been bitrotting for a while, and nobody really cared.

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?

(Note that this is not about removing support for any other sysvinit
compat, only really about /dev/initctl. Specifically, support for
commands like "init q" is completely independent of this, and is
supported fine inside of systemctl, and requires no /dev/initctl or
anything).

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel