Re: [systemd-devel] detect_container() for recent(?) docker

2020-01-28 Thread Dave Howorth
On Tue, 28 Jan 2020 15:28:08 +0300
"Matwey V. Kornilov"  wrote:
> вт, 28 янв. 2020 г. в 15:25, Lennart Poettering
> :

> > We document the requirements and expectations to run systemd in
> > containers very explicitly here:
> >
> > https://systemd.io/CONTAINER_INTERFACE  
> 
> If I could google this page, it would save lot of my time. Thanks a
> lot!

The order of hits in google is google's choice, of course, and not
systemd. Having said that, when I google for 'systemd container
interface' (without the quotes), the first hit is
https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
and the first thing that says is 'This page moved to
https://systemd.io/CONTAINER_INTERFACE '
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] detect_container() for recent(?) docker

2020-01-28 Thread Matwey V. Kornilov
вт, 28 янв. 2020 г. в 15:25, Lennart Poettering :
>
> On Di, 28.01.20 15:07, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:
>
> > Thanks for reply! I've just wanted to let you know about this issue
> > after spending couple hours trying to understand why my container
> > works on the one host and don't work on another one.
> > I think there are couple things which can be done here. First, it
> > would be great to modify the comment as proposed in PR 8200. If I knew
> > that this test is fuzzy, I would not write this mail.
> > Second, I didn't know about $container env until I read systemd
> > sources. There are a lot of fragmental information about running
> > systemd in docker in Internet, it would be great to have official
> > systemd-point-of-view on this topic.
>
> We document the requirements and expectations to run systemd in
> containers very explicitly here:
>
> https://systemd.io/CONTAINER_INTERFACE

If I could google this page, it would save lot of my time. Thanks a lot!

>
> The intention of that documentation is of course that container
> managers can make systemd payloads just work. To my knowledge most
> container managers implemented the bits necessary for that, but Docker
> people are not interested in this. There's little we can do about
> that.
>
> I am sorry you picked the one container implementation who's not
> interested in playing with the others, but there's nothing much we can
> do about that.
>
> Lennart
>
> --
> Lennart Poettering, Berlin



-- 
With best regards,
Matwey V. Kornilov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] detect_container() for recent(?) docker

2020-01-28 Thread Lennart Poettering
On Di, 28.01.20 15:07, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:

> Thanks for reply! I've just wanted to let you know about this issue
> after spending couple hours trying to understand why my container
> works on the one host and don't work on another one.
> I think there are couple things which can be done here. First, it
> would be great to modify the comment as proposed in PR 8200. If I knew
> that this test is fuzzy, I would not write this mail.
> Second, I didn't know about $container env until I read systemd
> sources. There are a lot of fragmental information about running
> systemd in docker in Internet, it would be great to have official
> systemd-point-of-view on this topic.

We document the requirements and expectations to run systemd in
containers very explicitly here:

https://systemd.io/CONTAINER_INTERFACE

The intention of that documentation is of course that container
managers can make systemd payloads just work. To my knowledge most
container managers implemented the bits necessary for that, but Docker
people are not interested in this. There's little we can do about
that.

I am sorry you picked the one container implementation who's not
interested in playing with the others, but there's nothing much we can
do about that.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] detect_container() for recent(?) docker

2020-01-28 Thread Matwey V. Kornilov
вт, 28 янв. 2020 г. в 11:36, Lennart Poettering :

>
> On So, 26.01.20 11:55, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:
>
> > Hello,
> >
> > I've just found that an assumption used inside detect_container() is
> > not always true, and that leads to virtualization misdetection.
> > Namely, I am running systemd inside docker (19.03.5) container on
> > ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
> >
> > /* Interestingly /proc/1/sched actually shows the host's PID
> > for what we see as PID 1. If the PID
> >  * shown there is not 1, we know we are in a PID namespace and
> > hence a container. */
> >  check_sched:
> > r = read_one_line_file("/proc/1/sched", );
> >
> > However, I see the following when reading this file in the container:
> >
> > 64813fe8f025:/ # cat /proc/1/sched
> > bash (1, #threads: 1)
>
> Yes, this is known, and to our knowledge not really fixable, as
> there's no nice way to detect containers entirely generically these
> days (or more specifically: detect whether we are in a pidns that is
> not the main one).
>
> Also see:
>
> https://github.com/systemd/systemd/pull/8200
>
> > Unfortunately, this leads to virtualization misdetection on systemd
> > startup (docker host runs inside kvm):
>
> So, docker is the only container engine to my knowledge that refuses
> to play nice by default and is thus unwilling to implement the
> $container env var by default. To make the container env detectable
> you hence have to set the env var manually in your containers.
>
> Sorry for that, but there's nothing we can do about this. The kernel took
> the only somewhat generic mechanism to detect containers away from us
> and the Docker people aren't willing to make their stuff detectable,
> hence there's nothing we can do.
>

Hi,

Thanks for reply! I've just wanted to let you know about this issue
after spending couple hours trying to understand why my container
works on the one host and don't work on another one.
I think there are couple things which can be done here. First, it
would be great to modify the comment as proposed in PR 8200. If I knew
that this test is fuzzy, I would not write this mail.
Second, I didn't know about $container env until I read systemd
sources. There are a lot of fragmental information about running
systemd in docker in Internet, it would be great to have official
systemd-point-of-view on this topic.

> Lennart
>
> --
> Lennart Poettering, Berlin



--
With best regards,
Matwey V. Kornilov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] detect_container() for recent(?) docker

2020-01-28 Thread Lennart Poettering
On So, 26.01.20 11:55, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:

> Hello,
>
> I've just found that an assumption used inside detect_container() is
> not always true, and that leads to virtualization misdetection.
> Namely, I am running systemd inside docker (19.03.5) container on
> ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
>
> /* Interestingly /proc/1/sched actually shows the host's PID
> for what we see as PID 1. If the PID
>  * shown there is not 1, we know we are in a PID namespace and
> hence a container. */
>  check_sched:
> r = read_one_line_file("/proc/1/sched", );
>
> However, I see the following when reading this file in the container:
>
> 64813fe8f025:/ # cat /proc/1/sched
> bash (1, #threads: 1)

Yes, this is known, and to our knowledge not really fixable, as
there's no nice way to detect containers entirely generically these
days (or more specifically: detect whether we are in a pidns that is
not the main one).

Also see:

https://github.com/systemd/systemd/pull/8200

> Unfortunately, this leads to virtualization misdetection on systemd
> startup (docker host runs inside kvm):

So, docker is the only container engine to my knowledge that refuses
to play nice by default and is thus unwilling to implement the
$container env var by default. To make the container env detectable
you hence have to set the env var manually in your containers.

Sorry for that, but there's nothing we can do about this. The kernel took
the only somewhat generic mechanism to detect containers away from us
and the Docker people aren't willing to make their stuff detectable,
hence there's nothing we can do.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel