Detecting the init system in use

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Detecting the init system in use

Robie Basak-4
The "official" way to detect if systemd is running appears to be to
check if the directory /run/systemd/system exists (from sd_booted(3)).
Our init-system-helpers package uses this test for example, and the test
correctly handles edge cases where one init system is installed but
another is in use such as when Trusty is upgraded to Xenial but has not
been rebooted yet.

However, the systemd SRU to Trusty in bug 1656280[1] regressed the
result of this test, resulting in bug 1732703[2].

Rather than have an ad-hoc solution I feel is brittle in case we have to
SRU systemd in Trusty again, I'd prefer to have consensus on what
Ubuntu's position is on checking the init system in use, and then we can
make sure to be consistent across all packages and (if possible) all
series.

I see three options:

1) Fix systemd on Trusty so that testing for /run/systemd/system works
again. This will probably need to remove /run/systemd/system correctly
on postinst as part of the fix. This will unbreak MAAS and snapd working
together.

2) Come up with and agree on some other universal way for testing for
systemd and make that work everywhere. Then we can SRU that test to MAAS
in Trusty, and fix any other packages in Trusty affected by the
behaviour change of the original test.

3) Accept that on Trusty the general case is now broken, and make the
official test be something like the following. This will need to be
SRU'd to MAAS in Trusty, and we'll need to fix any other packages in
Trusty affected by the behaviour change of the original test.

   if Trusty: upstart
   else if [ -d /run/systemd/system ]: systemd
   else [existing checks for other init systems]

Are there any other options? Please discuss as you wish. My purpose in
starting this thread is to record consensus once we have it, so the
archive of this thread can be used to be consistent in how we handle
fixing this.

It occurs to me that another class of use cases the test behaviour
change might have broken are configuration management tools, which all
generally need to know what init system is in use in order to manage
services. I have not investigated this though.

Thanks,

Robie

[1] https://launchpad.net/bugs/1656280
[2] https://launchpad.net/bugs/1732703

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Detecting the init system in use

Jonathon Fernyhough
On 13/12/17 17:57, Robie Basak wrote:
> 2) Come up with and agree on some other universal way for testing for
> systemd and make that work everywhere. Then we can SRU that test to MAAS
> in Trusty, and fix any other packages in Trusty affected by the
> behaviour change of the original test.

Possibly too simplistic, but,

On a 14.04 system:

$ file /sbin/init
/sbin/init: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=7a4c688d009fc1f06ffc692f5f42ab09e68582b2, stripped

On a 16.04 system:

$ file /sbin/init
/sbin/init: symbolic link to /lib/systemd/systemd


Other "pure-systemd" systems (e.g. Arch) use a symlink similar to 16.04
so this should work with later Ubuntu releases too:

$ file /sbin/init
/sbin/init: symbolic link to ../lib/systemd/systemd


J


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Detecting the init system in use

Martin Pitt-4
In reply to this post by Robie Basak-4
Robie Basak [2017-12-13 17:57 +0000]:
> 1) Fix systemd on Trusty so that testing for /run/systemd/system works
> again. This will probably need to remove /run/systemd/system correctly
> on postinst as part of the fix. This will unbreak MAAS and snapd working
> together.

It may work  to adjust the upstart job that starts the deputy init systemd to
create its own mount namespace, do a shared bind-mount of the host's
/run/systemd/ its own namespace, and then do a private tmpfs mount on
/run/systemd/system/ . Then only pid 1 itself should see /run/systemd/system/.
This of course might break systemd-y things that try to read this, but usually
there's not much in this dir anyway.

I haven't tried this, just as a thought for experimentation.

Pitti

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Detecting the init system in use

Jamie Strandboge-3
On Wed, 2017-12-13 at 22:03 +0100, Martin Pitt wrote:

> Robie Basak [2017-12-13 17:57 +0000]:
> > 1) Fix systemd on Trusty so that testing for /run/systemd/system
> > works
> > again. This will probably need to remove /run/systemd/system
> > correctly
> > on postinst as part of the fix. This will unbreak MAAS and snapd
> > working
> > together.
>
> It may work  to adjust the upstart job that starts the deputy init
> systemd to
> create its own mount namespace, do a shared bind-mount of the host's
> /run/systemd/ its own namespace, and then do a private tmpfs mount on
> /run/systemd/system/ . Then only pid 1 itself should see
> /run/systemd/system/.
> This of course might break systemd-y things that try to read this,
> but usually
> there's not much in this dir anyway.
>
> I haven't tried this, just as a thought for experimentation.
I suspect this might confuse snapd/snap-confine for manipulating snap
mount namespaces. CC'ing zyga to comment.

--
Jamie Strandboge             | http://www.canonical.com
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Detecting the init system in use

Mike Pontillo-2
In reply to this post by Robie Basak-4
On Wed, Dec 13, 2017 at 9:57 AM, Robie Basak <[hidden email]> wrote:
1) Fix systemd on Trusty so that testing for /run/systemd/system works
again. This will probably need to remove /run/systemd/system correctly
on postinst as part of the fix. This will unbreak MAAS and snapd working
together.

2) Come up with and agree on some other universal way for testing for
systemd and make that work everywhere. Then we can SRU that test to MAAS
in Trusty, and fix any other packages in Trusty affected by the
behaviour change of the original test.

3) Accept that on Trusty the general case is now broken, and make the
official test be something like the following. This will need to be
SRU'd to MAAS in Trusty, and we'll need to fix any other packages in
Trusty affected by the behaviour change of the original test.

   if Trusty: upstart
   else if [ -d /run/systemd/system ]: systemd
   else [existing checks for other init systems]

Are there any other options? Please discuss as you wish. My purpose in
starting this thread is to record consensus once we have it, so the
archive of this thread can be used to be consistent in how we handle
fixing this.

We discussed this from the MAAS angle recently, and one of the options the team came up with was to check what binary the `/proc/1/exe`link points to. Unfortunately, you can't do that without elevated privileges, but we could ship a simple setuid/setcap utility to do so. I've got a quick proof-of-concept here, if that's an option:


That said, MAAS 1.9 is intended to run on Trusty, and 2.0 through 2.3 are intended to run on Xenial. Due to other dependencies that changed between Trusty and Xenial, I don't think it would be practical to support MAAS on a "Frankenstein" Trusty system that has been upgraded to Xenial but not rebooted.

So that's somewhat a combination of (2) and (3). I think it's difficult to predict if the benefit of doing (1) is worth the effort.

Regards,
Mike

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Detecting the init system in use

Dimitri John Ledkov
In reply to this post by Jamie Strandboge-3
On 13 December 2017 at 22:15, Jamie Strandboge <[hidden email]> wrote:

> On Wed, 2017-12-13 at 22:03 +0100, Martin Pitt wrote:
>> Robie Basak [2017-12-13 17:57 +0000]:
>> > 1) Fix systemd on Trusty so that testing for /run/systemd/system
>> > works
>> > again. This will probably need to remove /run/systemd/system
>> > correctly
>> > on postinst as part of the fix. This will unbreak MAAS and snapd
>> > working
>> > together.
>>
>> It may work  to adjust the upstart job that starts the deputy init
>> systemd to
>> create its own mount namespace, do a shared bind-mount of the host's
>> /run/systemd/ its own namespace, and then do a private tmpfs mount on
>> /run/systemd/system/ . Then only pid 1 itself should see
>> /run/systemd/system/.
>> This of course might break systemd-y things that try to read this,
>> but usually
>> there's not much in this dir anyway.
>>
>> I haven't tried this, just as a thought for experimentation.
>
> I suspect this might confuse snapd/snap-confine for manipulating snap
> mount namespaces. CC'ing zyga to comment.

My suspicion was that indeed this would break using snaps classical
(unconfined?) on trusty.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Detecting the init system in use

Martin Pitt-2
In reply to this post by Robie Basak-4
Hello all,

Robie Basak [2017-12-13 17:57 +0000]:
> 3) Accept that on Trusty the general case is now broken, and make the
> official test be something like the following. This will need to be
> SRU'd to MAAS in Trusty, and we'll need to fix any other packages in
> Trusty affected by the behaviour change of the original test.
>
>    if Trusty: upstart
>    else if [ -d /run/systemd/system ]: systemd
>    else [existing checks for other init systems]

After the discussion and seeing the alternatives, this now appears as the
safest and most robust option to me; particularly as this is going to be
introduced as SRUs, and making complicated changes with new namespaces, suid
helpers,  etc. is going to introduce a lot more subtle regressions than it
helps.

Martin

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment