3 ms·

Interestingly, systemd maintainers have consistently refused to make available a Docker compatible version of systemd to run as the init 1. Everyone brings the

Interestingly, systemd maintainers have consistently refused to make available a Docker compatible version of systemd to run as the init 1. Everyone brings their own here (e.g. http://phusion.github.io/baseimage-docker/ http://phusion.github.io/baseimage-docker/) like supervisord, runit,etc. What would have been ideal is for a docker-compatible systemd to run inside the container. IMHO the maintainers are bent on creating a competing standard (like this one) and don't want to build anything that brings the advantages of systemd to the Docker ecosystem.

TheDong 8y ago
> Interestingly, systemd maintainers have consistently refused to make available a Docker compatible version of systemd to run as the init 1. Please provide evidence of that. I will provide counter-evidence, proving that is not the case unless you have very compelling evidence. 1. https://lists.freedesktop.org/archives/systemd-devel/2014-May/019005.html https://lists.freedesktop.org/archives/systemd-devel/2014-Ma... Poettering writes: > To say this explicitly: we are really interested in making sure that systemd runs out-of-the-box in containers, and docker is just one implementation of that. 2. A PR to make systemd-logind work better in a docker container is accepted with no issue: https://github.com/systemd/systemd/pull/4154 https://github.com/systemd/systemd/pull/4154 3. Running systemd as pid1 in docker (privileged or not) works, so clearly the maintainers didn't do a good job of preventing it from happening. (just google, there's plenty of info out there on how to do this) I'm sure there are many other examples too, but this is with a quick glance around. I'd be interested in your reference before you spread such strange FUD.
- sandGorgon 8y ago
  there you go - https://bugs.freedesktop.org/show_bug.cgi?id=88986 https://bugs.freedesktop.org/show_bug.cgi?id=88986 this is a bug I filed. Lennart's reply: We had support for this in systemd in the initial versions, but since nobody was using and testing this, and the semantics were different from the system version in subtle ways we removed support for it. Also note that systemd requires kernel 3.7 as minimal version right now. You cannot run it on older kernels, and hence really old operating systems anyway. Sorry, but this is nothing we want or can support! I admit that it is 2 years old - and if it has changed, then that would be nice. But there is an explicit reply there.. and I'm not spreading FUD. There's nothing more that I would love than to replace all the supervisord stuff in Docker with systemd.
  - TheDong 8y ago
    Your original comment was about running docker in systemd. That bug doesn't appear to be closely related. You wrote: "... it would be great if there was a way we could use systemd+journald in older OS to run applications". That's what Lennart replied to. He didn't dismiss using it in containers as pid1, he dismissed running it on arbitrary older linuxes as pid != 1... those are completely different scenarios. I do not find any support in that link for your original comment, so unless you have more evidence or can explain how I'm misunderstanding your bug, I still consider you to be spreading FUD.
    - sandGorgon 8y ago
      That is not fair. Because I have explicitly mentioned this in the bug. Quote unquote Docker is only making things even worse - the recommended way of using Docker is shifting gradually to be using poorly-suited PID 1 processes like supervisord. Additionally, there are other places where I mention Docker as a use case. Granted that English is not my first language, but I do not think there was confusion on this being around Docker. In addition the bug title is " Standalone version of systemd to act as a process control system" ...Which was as generic as I could make it. Running an arbitrary job-runner on older system is an implicit use case....But by explicit clarification, I brought in the Docker use case as well. I also explicitly mentioned that we are prepared to use newer kernels within Docker if that is important. P.S. Already, a lot of us work with upgraded kernels because of Docker and this is already acceptable. I WANT to use systemd - but I stand by my claim that this bug is sufficient illustration that there is no intent to support the docker ecosystem. I do not wish to start a flamewar, but I categorically reject your claims of me spreading FUD as deliberately malicious.
      - TheDong 8y ago
        You replied with those lines after the bug was already resolved, and they don't match with your primary bug report well. In fact, they contradict your primary report where you wrote "I do not believe we will upgrade older computers to newer OS" and "it would be great if there was a way we could use systemd+journald in older OS" and "I do understand that systemd needs to be pid 1, but I wonder if a subset of functionality can still be exposed when it is not running as pid 1". Again, all of those things are entirely unrelated to it running as a pid1 in a container, and those parts of your original bug report are what Poettering responded to. You're reading way too much into that one bug. In fact, you could already run systemd in docker before you posted that bug if you go back to my first link to a mailing list thread about the very subject from 2014. Your main bug report made it sound like you were asking to run systemd as pid != 1, which is unrelated to running systemd in docker. Your clarification here only convinces me that you hold a grudge against systemd and wish to interpret benign comments in a bad light because, no matter how many times I read that bug, I cannot understand your claim that the original posting and Poettering's rejection of it is in any way related to running systemd in docker.
- cyphar 8y ago
  I would recommend speaking to someone from the LXC team. I only know of their systemd pains second-hand, but there are many many many things that systemd has done throughout its history that made it a royal pain to run in a container. I also have my own battle-scars from systemd but they are mostly related to systemd on the host rather than inside a container. Here's one piece of evidence though[1]. Effectively systemd enabled a security feature for the host's /dev/console and when we said it wasn't necessary for containers (because /dev/console is not a real console) and it actually broke runc, Lennart said that we should fix runc. [1]: https://github.com/systemd/systemd/pull/4262 https://github.com/systemd/systemd/pull/4262
  - JdeBP 8y ago
    That discussion does not match your summary of it. This wasn't a security feature that got enabled. This was an expectation of the long-standing semantics of /dev/console, which as M. Poettering pointed out long pre-date systemd, being broken by a container manager. So yes, it's right that the container manager be fixed so that it is possible for every open file descriptor for /dev/console to be closed and then the device re-opened again. Such semantics have been around longer than Linux itself has; systemd is written to expect them. /dev/console is not supposed to magically vanish/become inoperable once all currently open file descriptors for it have been closed. Quite a lot of other softwares, including everything that uses openlog() with LOG_CONS, expect this of /dev/console too. Indeed, /dev/console is one of the very few device files mandated to exist by the Single UNIX Specification (XBD part 10). The container manager was actually setting up an execution environment that is not POSIX conformant. And I observe that indeed said container manager did get fixed. * https://github.com/containerd/console/pull/10 https://github.com/containerd/console/pull/10
    - cyphar 8y ago
      GP was arguing that the idea that systemd would refuse to make a change that would benefit running inside containers was ridiculous and required evidence. I have required that evidence -- it is an example of a change in systemd being rejected in favour of fixing it in the container runtime. Of course we fixed it, and of course you can argue that Lennart was correct (I still think that having SAK protections in a container is nonsensical but that's all water under the bridge). I obviously agree that our /dev/console handling was incorrect. In our defense, /dev/console doesn't actually make much sense in a container since the purpose of /dev/console is to access the physical console not the current PTY -- so anything we put there would still be "wrong" from the standpoint of POSIX. But you can't just ignore /dev/console because then a bunch of programs don't work. I could also go on about how it was also a Go stdlib issue because we'd assumed io.Copy "did the right thing" but it turns out it really doesn't handle any form of interruptions properly. But I'm sure you're not interested in that discussion. The point is that I agree it was fixed, and I agree that fixing it in the container runtime was overall correct. But that wasn't the point I was making -- it was that there have been examples where systemd has made a change that broke running inside a container and they were not willing to make concessions for container runtimes. Which is what GP was arguing about. I do have plenty of other examples (cgroups are particularly fruitful for systemd bugs that won't die), but they aren't really related to running inside a container. [ I'm not a hater of systemd, or Lennart. I actually really like having a declarative service manager. My frustration comes from having to deal with it when developing system tools that don't want to be tightly coupled with it. That's where systemd really starts to get ugly to deal with. ] > M. Poettering What does the 'M' stand for? His first name is Lennart.
diffeomorphism 8y ago
Doesn't rkt use systemd exactly in that way? https://coreos.com/rkt/#features https://coreos.com/rkt/#features What were the maintainers supposedly refusing?
ofrzeta 8y ago
Since version 1.13 Docker has a built-in init based on https://github.com/krallin/tini https://github.com/krallin/tini

TheDong 8y ago

> Interestingly, systemd maintainers have consistently refused to make available a Docker compatible version of systemd to run as the init 1. Please provide evidence of that. I will provide counter-evidence, proving that is not the case unless you have very compelling evidence. 1. https://lists.freedesktop.org/archives/systemd-devel/2014-May/019005.html https://lists.freedesktop.org/archives/systemd-devel/2014-Ma... Poettering writes: > To say this explicitly: we are really interested in making sure that systemd runs out-of-the-box in containers, and docker is just one implementation of that. 2. A PR to make systemd-logind work better in a docker container is accepted with no issue: https://github.com/systemd/systemd/pull/4154 https://github.com/systemd/systemd/pull/4154 3. Running systemd as pid1 in docker (privileged or not) works, so clearly the maintainers didn't do a good job of preventing it from happening. (just google, there's plenty of info out there on how to do this) I'm sure there are many other examples too, but this is with a quick glance around. I'd be interested in your reference before you spread such strange FUD.

sandGorgon 8y ago
there you go - https://bugs.freedesktop.org/show_bug.cgi?id=88986 https://bugs.freedesktop.org/show_bug.cgi?id=88986 this is a bug I filed. Lennart's reply: We had support for this in systemd in the initial versions, but since nobody was using and testing this, and the semantics were different from the system version in subtle ways we removed support for it. Also note that systemd requires kernel 3.7 as minimal version right now. You cannot run it on older kernels, and hence really old operating systems anyway. Sorry, but this is nothing we want or can support! I admit that it is 2 years old - and if it has changed, then that would be nice. But there is an explicit reply there.. and I'm not spreading FUD. There's nothing more that I would love than to replace all the supervisord stuff in Docker with systemd.
- TheDong 8y ago
  Your original comment was about running docker in systemd. That bug doesn't appear to be closely related. You wrote: "... it would be great if there was a way we could use systemd+journald in older OS to run applications". That's what Lennart replied to. He didn't dismiss using it in containers as pid1, he dismissed running it on arbitrary older linuxes as pid != 1... those are completely different scenarios. I do not find any support in that link for your original comment, so unless you have more evidence or can explain how I'm misunderstanding your bug, I still consider you to be spreading FUD.
  - sandGorgon 8y ago
    That is not fair. Because I have explicitly mentioned this in the bug. Quote unquote Docker is only making things even worse - the recommended way of using Docker is shifting gradually to be using poorly-suited PID 1 processes like supervisord. Additionally, there are other places where I mention Docker as a use case. Granted that English is not my first language, but I do not think there was confusion on this being around Docker. In addition the bug title is " Standalone version of systemd to act as a process control system" ...Which was as generic as I could make it. Running an arbitrary job-runner on older system is an implicit use case....But by explicit clarification, I brought in the Docker use case as well. I also explicitly mentioned that we are prepared to use newer kernels within Docker if that is important. P.S. Already, a lot of us work with upgraded kernels because of Docker and this is already acceptable. I WANT to use systemd - but I stand by my claim that this bug is sufficient illustration that there is no intent to support the docker ecosystem. I do not wish to start a flamewar, but I categorically reject your claims of me spreading FUD as deliberately malicious.
    - TheDong 8y ago
      You replied with those lines after the bug was already resolved, and they don't match with your primary bug report well. In fact, they contradict your primary report where you wrote "I do not believe we will upgrade older computers to newer OS" and "it would be great if there was a way we could use systemd+journald in older OS" and "I do understand that systemd needs to be pid 1, but I wonder if a subset of functionality can still be exposed when it is not running as pid 1". Again, all of those things are entirely unrelated to it running as a pid1 in a container, and those parts of your original bug report are what Poettering responded to. You're reading way too much into that one bug. In fact, you could already run systemd in docker before you posted that bug if you go back to my first link to a mailing list thread about the very subject from 2014. Your main bug report made it sound like you were asking to run systemd as pid != 1, which is unrelated to running systemd in docker. Your clarification here only convinces me that you hold a grudge against systemd and wish to interpret benign comments in a bad light because, no matter how many times I read that bug, I cannot understand your claim that the original posting and Poettering's rejection of it is in any way related to running systemd in docker.
cyphar 8y ago
I would recommend speaking to someone from the LXC team. I only know of their systemd pains second-hand, but there are many many many things that systemd has done throughout its history that made it a royal pain to run in a container. I also have my own battle-scars from systemd but they are mostly related to systemd on the host rather than inside a container. Here's one piece of evidence though[1]. Effectively systemd enabled a security feature for the host's /dev/console and when we said it wasn't necessary for containers (because /dev/console is not a real console) and it actually broke runc, Lennart said that we should fix runc. [1]: https://github.com/systemd/systemd/pull/4262 https://github.com/systemd/systemd/pull/4262
- JdeBP 8y ago
  That discussion does not match your summary of it. This wasn't a security feature that got enabled. This was an expectation of the long-standing semantics of /dev/console, which as M. Poettering pointed out long pre-date systemd, being broken by a container manager. So yes, it's right that the container manager be fixed so that it is possible for every open file descriptor for /dev/console to be closed and then the device re-opened again. Such semantics have been around longer than Linux itself has; systemd is written to expect them. /dev/console is not supposed to magically vanish/become inoperable once all currently open file descriptors for it have been closed. Quite a lot of other softwares, including everything that uses openlog() with LOG_CONS, expect this of /dev/console too. Indeed, /dev/console is one of the very few device files mandated to exist by the Single UNIX Specification (XBD part 10). The container manager was actually setting up an execution environment that is not POSIX conformant. And I observe that indeed said container manager did get fixed. * https://github.com/containerd/console/pull/10 https://github.com/containerd/console/pull/10
  - cyphar 8y ago
    GP was arguing that the idea that systemd would refuse to make a change that would benefit running inside containers was ridiculous and required evidence. I have required that evidence -- it is an example of a change in systemd being rejected in favour of fixing it in the container runtime. Of course we fixed it, and of course you can argue that Lennart was correct (I still think that having SAK protections in a container is nonsensical but that's all water under the bridge). I obviously agree that our /dev/console handling was incorrect. In our defense, /dev/console doesn't actually make much sense in a container since the purpose of /dev/console is to access the physical console not the current PTY -- so anything we put there would still be "wrong" from the standpoint of POSIX. But you can't just ignore /dev/console because then a bunch of programs don't work. I could also go on about how it was also a Go stdlib issue because we'd assumed io.Copy "did the right thing" but it turns out it really doesn't handle any form of interruptions properly. But I'm sure you're not interested in that discussion. The point is that I agree it was fixed, and I agree that fixing it in the container runtime was overall correct. But that wasn't the point I was making -- it was that there have been examples where systemd has made a change that broke running inside a container and they were not willing to make concessions for container runtimes. Which is what GP was arguing about. I do have plenty of other examples (cgroups are particularly fruitful for systemd bugs that won't die), but they aren't really related to running inside a container. [ I'm not a hater of systemd, or Lennart. I actually really like having a declarative service manager. My frustration comes from having to deal with it when developing system tools that don't want to be tightly coupled with it. That's where systemd really starts to get ugly to deal with. ] > M. Poettering What does the 'M' stand for? His first name is Lennart.

diffeomorphism 8y ago

Doesn't rkt use systemd exactly in that way? https://coreos.com/rkt/#features https://coreos.com/rkt/#features What were the maintainers supposedly refusing?

ofrzeta 8y ago

Since version 1.13 Docker has a built-in init based on https://github.com/krallin/tini https://github.com/krallin/tini