7 ms·

Systemd vs. Docker

99 points by tomaac 11y ago

pmoriarty 11y ago
CoreOS's Rocket is built around systemd? That alone disqualifies it for me right there.
- baldfat 11y ago
  > That alone disqualifies it for me right there For philosophy reasons? Can people just not accept that systemd is the main solution that the community has accepted and move along?
  - jimktrains2 11y ago
    Or they can move to one of the BSDs and use jails which are much more stable, secure, and tested than linux containers.
    - xaduha 11y ago
      Technology isn't that important here, it's what stems from it is. Adoption, infrastructure, tools, community. There's also a price for doing it differently. And believe you me, using BSD nowadays is the definition of doing things differently. What for? What I'm getting for losing my time and reinventing the tools that are already available and much more polished? Dockerfiles can be replicated. Docker Hub can be replicated. Missing things can be compiled from sources, probably. But all that costs time for little to no gain.
      - protomyth 11y ago
        That's basically the argument to use Windows and Windows-based technology and not Linux. Everything you can do on any of the UNIX boxes, you can do with Windows. It might be different, but it is still a more popular / supported platform. Since I'm not a Windows fan, I find value in doing it differently, and so have Linux fans. I think you will find FreeBSD and SmartOS users find the cost in time to bring a large enough gain to satisfy their business requirements.
        xaduha 11y ago
        > That's basically the argument to use Windows and Windows-based technology and not Linux. Not today it isn't. Years, maybe decades ago it could be. What Linux containers do is help to remove the barrier that various distributions introduced, it makes things more accessible and it's more lightweight than using virtualization. Centos, Alpine, Ubuntu, whatever. As long as it is in a container I can work with it. I can even run some Windows binaries with Wine inside a container. rkt is largely compatible with Docker infrastructure, so that too is fine. But what jimktrains2 suggesting is complete opposite of that, it reduces options.
        laumars 11y ago
        > But what jimktrains2 suggesting is complete opposite of that, it reduces options. Personally I'd consider having familiarity with more than one platform would increase one's options. But ultimately having other solutions on the market is a good thing. Not only because no one solution is the best at every metric (be it stability, security, speed, memory usage, nor any specific requirements), nor because different solutions can appeal to different personalities. But mostly because different solutions might solve a problem in a unique way that the competing solutions may not have considered - often in ways that can ported and thus benefit the competitors and wider community. So I wouldn't be so quick to dismiss anything that's outside your field of expertise.
        xaduha 11y ago
        What you're talking about is a luxury I can't afford. That's what I mean when I talk about the price. There are plenty of far more important technologies that I would rather learn. I can't afford to learn two technologies that do about the same thing, of which one is significantly less popular, might now have tools that other has and runs on a significantly less popular OS.
        laumars 11y ago
        That's actually a fair point and one I completely sympathise with. But your original argument very much sounded like you were suggesting that people in general shouldn't bother with FreeBSD, jails, nor any other technologies which weren't dominant in their respective field. Which is why we disagreed.
      - laumars 11y ago
        You do realise that "different" platforms can still be popular enough to have a lot of the same ecosystems. Hell, Docker itself used to be the "alternative"; not even that long ago in fact. FreeBSD might only have a fraction of the community that Linux does, but that's still a pretty large number of developers and sysadmins in real world terms. Disclosure: I run both FreeBSD and Linux systems.
        xaduha 11y ago
        And your point is? A suggestion to switch to BSD and jails for an average user of Docker is laughable.
        laumars 11y ago
        Well if someone is competent enough to create a Docker image then it's not a great stretch to assume many of them would also be competent enough to create a jail. And FreeBSD is just as easy to use as Linux (actually, I generally find it easier to administrate than Linux since things are more rigorously laid out. But a lot of that is also down to my own personal preference). At the end of the day, both Jails and Docker are well documented. So even the people only interested in blindly copying and pasting commands should be able do the basics. The real problem FreeBSD and jails face isn't with support nor accessibility but rather dumb prejudice. Much like why many Windows users think Linux is difficult. If you spend your whole time shouting that your way of doing things is the best then you're never going to give anything else a fair chance.
        xaduha 11y ago
        You're missing the point. Even if jails is the most elegant, easy and powerful technology in the world it's still on BSD. People are not going to switch to BSD just because of jails. Sure, then can use both, but why? Docker and linux containers in general made things easier and more accessible for many. Switching from that to jails doesn't make sense.
        laumars 11y ago
      - Wilya 11y ago
        Have you used both jails and Docker? Saying docker is a much more polished option doesn't match my experience. Yes, it has more features, but with these features come more bugs. Some of them are minor annoyances. Some are of the "our infrastructure is fucked until we switch our storage driver" kind. Sometimes, stability is a gain.
        xaduha 11y ago
        I'm not comparing Docker and jails, I'm talking about things around. Stackoverflow.com coverage, blogs posts and guides, github repos, publicly available images, etc.
      - JdeBP 11y ago
        > And believe you me, using BSD nowadays is the definition of doing things differently. ... although people like Florian Haas argue that the way that one does things on the BSDs is actually the way that makes sense to do things with Docker, as well, and the way that you think to be "different" is actually the sensible way overall. * https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN * https://www.hastexo.com/blogs/florian/2016/02/21/containers-just-because-everyone-else/ https://www.hastexo.com/blogs/florian/2016/02/21/containers-...
        xaduha 11y ago
        Choosing BSD instead of Linux is "doing things differently". I'm talking about popularity and what it means in this whole comment tree, not about technical merits.
    - JohnDoe365 11y ago
      Or they can move to a steam engine which are much more stable, secure, and tested than cars consuming gasoline. Embrace the change, it's for a better future.
      - 4ad 11y ago
        > Embrace the change, it's for a better future. Unfortunately, especially when you also factor in the impact of ZFS and DTrace, you are moving into the past, not the future.
        qwertyuiop924 11y ago
        Quite. Embrace the change of having less security, less control, and less capability to debug your software.
      - baldfat 11y ago
        Poster of embrace the community. They don't have to embrace the change they have other options. What bothers me is they chose to shoot down everything and anything that has systemd in it out in the public. Just leave the fight and just embrace your choice and allow others to have their choice and don't pee on their parade.
    - 4ad 11y ago
      > stable, secure, and tested That is true, however jails lose a lot of power without VIMAGE. VIMAGE is not enabled by default yet, and it's pretty unstable (I use it). I really wish VIMAGE would mature, but we're not there yet.
    - vidarh 11y ago
      Rocket is not limited to Linux containers. It can also run in VMs. Incidentally there are also solutions to run Docker containers in VMs (Rocket itself should able to, but there are others as well, like hyper.sh)
    - baldfat 11y ago
      Exactly that is your choice. I am concerned about the drama of systemd by people that don't like systemd always peeing on every and anything that mentions systemd. It is in the old rpm vs deb, vim vs emacs, python vs perl dram of the past.
      - qwertyuiop924 11y ago
        No, it isn't. Nobody is going to try to nuke my emacs install, and install vi on my machine instead. If vi started deleting emacs, or using non-utf8 encodings on all text for some reason, or otherwise made using emacs impossible, the vi developers would fix it, or the community would say, "What the FUCK!?" and probably fork it.
  - michaelmrose 11y ago
    The concept of the community is an abstraction and in this case a bad one. There is no community. There are a million different individuals and within that thousands of communities each composed of some subset of those individuals. There is no reason each subset or each individual even shouldn't have their own opinion and based their actions upon it.
    - baldfat 11y ago
      > There is no community The very foundation of Open Source / Free Software Movement is 100% community. The very foundation of Closed Source is "There is no community." Community isn't an abstraction but is what has built Linux. To quote RMS (Who I disagree most of the time but highly respect) >Tens of millions of people around the world now use free software; the public schools of some regions of India and Spain now teach all students to use the free GNU/Linux operating system. Most of these users, however, have never heard of the ethical reasons for which we developed this system and built the free software community, because nowadays this system and community are more often spoken of as “open source”, attributing them to a different philosophy in which these freedoms are hardly mentioned. http://www.gnu.org/philosophy/open-source-misses-the-point.en.html http://www.gnu.org/philosophy/open-source-misses-the-point.e... > There is no reason each subset or each individual even shouldn't have their own opinion and based their actions upon it 100% my point move to your choice and don't pee on systemd every time it is brought up. Your opinion is different then the majority in regards to systemd and you can use those options and not have to discount everyone else's choice.
      - deleted 11y ago
        [deleted]
- philips 11y ago
  rkt isn't built around systemd. It does use it internally and integrates well with it. Inside of rkt there is an internal logical separation between the tool that sets up the container filesystems and the one that executes them. We call those things stages[1]. Now inside of rkt we have a few different "stage1" options today: - systemd: this means that your container has a real init system - clear containers: execute the container inside of a virtual machine with lkvm.[2] - direct execution w/ fly: no init system is involved for special privileged containers.[3] If someone wanted to contribute a stage1 that used a different init system that would be great. But, today systemd works fine and is generally an implementation detail. We also get some bonuses by using systemd on systemd systems like machinectl integration, and journald integration. Also, I should note that rkt should work on non-systemd systems as well. Again, because, systemd is an internal detail. [1] https://coreos.com/rkt/docs/latest/devel/architecture.html#stage-0 https://coreos.com/rkt/docs/latest/devel/architecture.html#s... [2] https://coreos.com/blog/rkt-0.8-with-new-vm-support/ https://coreos.com/blog/rkt-0.8-with-new-vm-support/ [3] https://coreos.com/blog/rkt-0.15.0-introduces-rkt-fly.html https://coreos.com/blog/rkt-0.15.0-introduces-rkt-fly.html
- bryanlarsen 11y ago
  Why the systemd hate? Because it's a big monolithic project that takes over your system? You do realize that Docker is much more monolithic and opinionated than systemd, right?
  - agentgt 11y ago
    I really hope unikernels take off because I really hate dealing with both (particularly docker more so than systemd).
    - rdtsc 11y ago
      I am a bit with Cantrill on unikernels they sound cool to play with, but I would hate to debug issues with them in production.
      - agentgt 11y ago
        I'm curious what you mean by debug. If you mean monitor all of our apps send metrics, health checks, and logs over the wire I'm sure that is independent. What would docker allow you over the unikernel especially given the best practice push for docker images to only run one thing in a container? IMO with Unikernel Xen aka Hypervisors are the container holders instead of docker.
        vidarh 11y ago
        With a Docker container, I can exec into it and run strace, ltrace, gdb etc.. With a unikernel it all depends on what you have built into the unikernel. That might provide everything I need, or not. The issue is that we will need a lot of toolking to put unikernels on a sufficiently equal footing vs. being able to run decades worth of Linux tools directly in the containers.
        agentgt 11y ago
        The issue I have with that is the tooling you mention while stable and mature is actively being replaced by cloud tools because you really can't just debug a single machine in production when you have a cluster.. not to mention it is production so debug symbols might not even be available. I understand your point of the maturity w/ tooling but I see it as a serious failure if you have to log into a machine in production and run gdb or IMO any tool. Your app can and should provide healthchecks/monitoring so that you can see if there is a problem (this includes even a thread stack dump). I'm probably just biased and jaded as I have had some serious technical debt lost to Docker. It just feels like a VM on top of a VM on top of a VM of continuous things to break/learn... I want baremetal :)
thwarted 11y ago
Poettering says that PID 1 has special requirements. One of these is killing "zombie" processes that have been abandoned by their calling session. This is a real problem for Docker since the application runs as PID 1 and does not handle the zombie processes. For example, containers running the Oracle database can end up with thousands of zombie processes. Why does Poettering keep claiming this when he's the one who submitted the patch that adds the PR_SET_CHILD_SUBREAPER prctl(2) [0] functionality? [0] http://man7.org/linux/man-pages/man2/prctl.2.html http://man7.org/linux/man-pages/man2/prctl.2.html
- pas 11y ago
  I guess he's saying, that you can't just take any random binary and run it in a Docker container, because if that binary spawns a lot of children but does not wait for them, then you'll have a lot of zombies. Docker could run a minimal pid1 in each container to address this. Though if this had been a big issue I guess this would have been already fixed. Naturally, a proof of concept of the problem would be great. (Let's say a Dockerfile.)
  - atemerev 11y ago
    Supervisord is the officially blessed solution: https://docs.docker.com/engine/admin/using_supervisord/ https://docs.docker.com/engine/admin/using_supervisord/
    - masklinn 11y ago
      supervisord specifically documents that it's not an init and shouldn't be used as an init, that's the second paragraph of its home page: http://supervisord.org/index.html?highlight=init http://supervisord.org/index.html?highlight=init
    - DannoHung 11y ago
      That is literally not at all what that is suggesting.
  - vidarh 11y ago
atemerev 11y ago
I don't always run containerized applications, but when I do, I prefer them completely systemd-free, thank you. Sometimes I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels — anything, just anything without this abomination.
- bryanlarsen 11y ago
  Can you explain your position to me? I can understand somebody who dislikes systemd and dislikes docker. I can understand somebody who likes both systemd and docker. But disliking systemd but liking docker? That I don't understand. Any effective criticism of systemd that I've heard generally can also be applied to docker. Like yours: "I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels" works even better if you replace systemd with docker.
  - atemerev 11y ago
    Docker is just a toolkit for composing and networking layered OS images. It improves isolation of things and adheres to simple principles (immutable containers, restarting instead attempting to recover, etc.) It structures things better. Inter-container communication is deliberately simple (env variables and, recently, networking). Systemd spits on isolation, it embraces integration of everything. Supervision, logging, communication, IO, configuration, state management — everything goes through systemd. Everything is binary and opaque. Docker is transparent.
    - bryanlarsen 11y ago
      Your criticism of systemd still applies to docker. "Supervision, logging, communication, IO, configuration, state management — everything goes through docker" If I use systemd I have to type 'systemd logs' to get at my logs, or I can use a plugin to move it somewhere else. If I use docker I have to type 'docker logs', or I can use a plugin to move it somewhere else. etc. etc. P.S. Agree completely with your praise of Docker. I'm firmly in the 'love both systemd and docker and wish they got along' camp.
js2 11y ago
One of these is killing "zombie" processes that have been abandoned by their calling session. That's funny terminolgy, isn't it? Killing a process usually means sending it a signal, typically TERM or KILL, that causes it to exit. But a zombie process is one that has already exited, but hasn't been waited for by its parent, where its parent is either the process that spawned it, or if that process has died, the process with PID 1. This is usually referred to as reaping the zombie process, not killing it. AFAIK, a signal sent to a zombie process is simply ignored. Or do the quotes around zombie imply a different meaning, such as "zombie-like"?
- masklinn 11y ago
  No, it's a zombie in the normal sense, the killing here is not sending it a signal but reaping zombie processes (in the sense of personified death reaping souls) by waiting on it. Things would probably be clearer if the quotes were around "killing" rather than "zombie", mayhaps the interviewer/writer was unfamiliar with the terminology.
  - ibotty 11y ago
    I strongly doubt that! Josh knows the terminology. It was surly just an oversight.
- ChrisArgyle 11y ago
  If we're being technical the author should have wrote "reaping" not "killing". It's a very different process. The use of quotes is probably an acknowledgement that the term "zombie" is not universal. For example Linux uses "defunct" instead. Basically, zombie processes happen when a child process exits but the parent process--the one that spawned it--doesn't reap it. [1] [1] https://en.wikipedia.org/wiki/Zombie_process https://en.wikipedia.org/wiki/Zombie_process
storrgie 11y ago
why not systemd-nspawn (zoidberg voice) Seems like the way Fedora is packaging systemd for 24 is going to move systemd-nspawn to a level of maturity that will likely surpass some of the clunky issues folks have with running docker.

Systemd vs. Docker

99 points by tomaac 11y ago

pmoriarty 11y ago

CoreOS's Rocket is built around systemd? That alone disqualifies it for me right there.

baldfat 11y ago
> That alone disqualifies it for me right there For philosophy reasons? Can people just not accept that systemd is the main solution that the community has accepted and move along?
- jimktrains2 11y ago
  Or they can move to one of the BSDs and use jails which are much more stable, secure, and tested than linux containers.
  - xaduha 11y ago
    Technology isn't that important here, it's what stems from it is. Adoption, infrastructure, tools, community. There's also a price for doing it differently. And believe you me, using BSD nowadays is the definition of doing things differently. What for? What I'm getting for losing my time and reinventing the tools that are already available and much more polished? Dockerfiles can be replicated. Docker Hub can be replicated. Missing things can be compiled from sources, probably. But all that costs time for little to no gain.
    - protomyth 11y ago
      That's basically the argument to use Windows and Windows-based technology and not Linux. Everything you can do on any of the UNIX boxes, you can do with Windows. It might be different, but it is still a more popular / supported platform. Since I'm not a Windows fan, I find value in doing it differently, and so have Linux fans. I think you will find FreeBSD and SmartOS users find the cost in time to bring a large enough gain to satisfy their business requirements.
      - xaduha 11y ago
        > That's basically the argument to use Windows and Windows-based technology and not Linux. Not today it isn't. Years, maybe decades ago it could be. What Linux containers do is help to remove the barrier that various distributions introduced, it makes things more accessible and it's more lightweight than using virtualization. Centos, Alpine, Ubuntu, whatever. As long as it is in a container I can work with it. I can even run some Windows binaries with Wine inside a container. rkt is largely compatible with Docker infrastructure, so that too is fine. But what jimktrains2 suggesting is complete opposite of that, it reduces options.
        laumars 11y ago
        > But what jimktrains2 suggesting is complete opposite of that, it reduces options. Personally I'd consider having familiarity with more than one platform would increase one's options. But ultimately having other solutions on the market is a good thing. Not only because no one solution is the best at every metric (be it stability, security, speed, memory usage, nor any specific requirements), nor because different solutions can appeal to different personalities. But mostly because different solutions might solve a problem in a unique way that the competing solutions may not have considered - often in ways that can ported and thus benefit the competitors and wider community. So I wouldn't be so quick to dismiss anything that's outside your field of expertise.
        xaduha 11y ago
        What you're talking about is a luxury I can't afford. That's what I mean when I talk about the price. There are plenty of far more important technologies that I would rather learn. I can't afford to learn two technologies that do about the same thing, of which one is significantly less popular, might now have tools that other has and runs on a significantly less popular OS.
        laumars 11y ago
        That's actually a fair point and one I completely sympathise with. But your original argument very much sounded like you were suggesting that people in general shouldn't bother with FreeBSD, jails, nor any other technologies which weren't dominant in their respective field. Which is why we disagreed.
    - laumars 11y ago
      You do realise that "different" platforms can still be popular enough to have a lot of the same ecosystems. Hell, Docker itself used to be the "alternative"; not even that long ago in fact. FreeBSD might only have a fraction of the community that Linux does, but that's still a pretty large number of developers and sysadmins in real world terms. Disclosure: I run both FreeBSD and Linux systems.
      - xaduha 11y ago
        And your point is? A suggestion to switch to BSD and jails for an average user of Docker is laughable.
        laumars 11y ago
        Well if someone is competent enough to create a Docker image then it's not a great stretch to assume many of them would also be competent enough to create a jail. And FreeBSD is just as easy to use as Linux (actually, I generally find it easier to administrate than Linux since things are more rigorously laid out. But a lot of that is also down to my own personal preference). At the end of the day, both Jails and Docker are well documented. So even the people only interested in blindly copying and pasting commands should be able do the basics. The real problem FreeBSD and jails face isn't with support nor accessibility but rather dumb prejudice. Much like why many Windows users think Linux is difficult. If you spend your whole time shouting that your way of doing things is the best then you're never going to give anything else a fair chance.
        xaduha 11y ago
        You're missing the point. Even if jails is the most elegant, easy and powerful technology in the world it's still on BSD. People are not going to switch to BSD just because of jails. Sure, then can use both, but why? Docker and linux containers in general made things easier and more accessible for many. Switching from that to jails doesn't make sense.
        laumars 11y ago
    - Wilya 11y ago
      Have you used both jails and Docker? Saying docker is a much more polished option doesn't match my experience. Yes, it has more features, but with these features come more bugs. Some of them are minor annoyances. Some are of the "our infrastructure is fucked until we switch our storage driver" kind. Sometimes, stability is a gain.
      - xaduha 11y ago
        I'm not comparing Docker and jails, I'm talking about things around. Stackoverflow.com coverage, blogs posts and guides, github repos, publicly available images, etc.
    - JdeBP 11y ago
      > And believe you me, using BSD nowadays is the definition of doing things differently. ... although people like Florian Haas argue that the way that one does things on the BSDs is actually the way that makes sense to do things with Docker, as well, and the way that you think to be "different" is actually the sensible way overall. * https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN * https://www.hastexo.com/blogs/florian/2016/02/21/containers-just-because-everyone-else/ https://www.hastexo.com/blogs/florian/2016/02/21/containers-...
      - xaduha 11y ago
        Choosing BSD instead of Linux is "doing things differently". I'm talking about popularity and what it means in this whole comment tree, not about technical merits.
  - JohnDoe365 11y ago
    Or they can move to a steam engine which are much more stable, secure, and tested than cars consuming gasoline. Embrace the change, it's for a better future.
    - 4ad 11y ago
      > Embrace the change, it's for a better future. Unfortunately, especially when you also factor in the impact of ZFS and DTrace, you are moving into the past, not the future.
      - qwertyuiop924 11y ago
        Quite. Embrace the change of having less security, less control, and less capability to debug your software.
    - baldfat 11y ago
      Poster of embrace the community. They don't have to embrace the change they have other options. What bothers me is they chose to shoot down everything and anything that has systemd in it out in the public. Just leave the fight and just embrace your choice and allow others to have their choice and don't pee on their parade.
  - 4ad 11y ago
    > stable, secure, and tested That is true, however jails lose a lot of power without VIMAGE. VIMAGE is not enabled by default yet, and it's pretty unstable (I use it). I really wish VIMAGE would mature, but we're not there yet.
  - vidarh 11y ago
    Rocket is not limited to Linux containers. It can also run in VMs. Incidentally there are also solutions to run Docker containers in VMs (Rocket itself should able to, but there are others as well, like hyper.sh)
  - baldfat 11y ago
    Exactly that is your choice. I am concerned about the drama of systemd by people that don't like systemd always peeing on every and anything that mentions systemd. It is in the old rpm vs deb, vim vs emacs, python vs perl dram of the past.
    - qwertyuiop924 11y ago
      No, it isn't. Nobody is going to try to nuke my emacs install, and install vi on my machine instead. If vi started deleting emacs, or using non-utf8 encodings on all text for some reason, or otherwise made using emacs impossible, the vi developers would fix it, or the community would say, "What the FUCK!?" and probably fork it.
- michaelmrose 11y ago
  The concept of the community is an abstraction and in this case a bad one. There is no community. There are a million different individuals and within that thousands of communities each composed of some subset of those individuals. There is no reason each subset or each individual even shouldn't have their own opinion and based their actions upon it.
  - baldfat 11y ago
    > There is no community The very foundation of Open Source / Free Software Movement is 100% community. The very foundation of Closed Source is "There is no community." Community isn't an abstraction but is what has built Linux. To quote RMS (Who I disagree most of the time but highly respect) >Tens of millions of people around the world now use free software; the public schools of some regions of India and Spain now teach all students to use the free GNU/Linux operating system. Most of these users, however, have never heard of the ethical reasons for which we developed this system and built the free software community, because nowadays this system and community are more often spoken of as “open source”, attributing them to a different philosophy in which these freedoms are hardly mentioned. http://www.gnu.org/philosophy/open-source-misses-the-point.en.html http://www.gnu.org/philosophy/open-source-misses-the-point.e... > There is no reason each subset or each individual even shouldn't have their own opinion and based their actions upon it 100% my point move to your choice and don't pee on systemd every time it is brought up. Your opinion is different then the majority in regards to systemd and you can use those options and not have to discount everyone else's choice.
    - deleted 11y ago
      [deleted]
philips 11y ago
rkt isn't built around systemd. It does use it internally and integrates well with it. Inside of rkt there is an internal logical separation between the tool that sets up the container filesystems and the one that executes them. We call those things stages[1]. Now inside of rkt we have a few different "stage1" options today: - systemd: this means that your container has a real init system - clear containers: execute the container inside of a virtual machine with lkvm.[2] - direct execution w/ fly: no init system is involved for special privileged containers.[3] If someone wanted to contribute a stage1 that used a different init system that would be great. But, today systemd works fine and is generally an implementation detail. We also get some bonuses by using systemd on systemd systems like machinectl integration, and journald integration. Also, I should note that rkt should work on non-systemd systems as well. Again, because, systemd is an internal detail. [1] https://coreos.com/rkt/docs/latest/devel/architecture.html#stage-0 https://coreos.com/rkt/docs/latest/devel/architecture.html#s... [2] https://coreos.com/blog/rkt-0.8-with-new-vm-support/ https://coreos.com/blog/rkt-0.8-with-new-vm-support/ [3] https://coreos.com/blog/rkt-0.15.0-introduces-rkt-fly.html https://coreos.com/blog/rkt-0.15.0-introduces-rkt-fly.html
bryanlarsen 11y ago
Why the systemd hate? Because it's a big monolithic project that takes over your system? You do realize that Docker is much more monolithic and opinionated than systemd, right?
- agentgt 11y ago
  I really hope unikernels take off because I really hate dealing with both (particularly docker more so than systemd).
  - rdtsc 11y ago
    I am a bit with Cantrill on unikernels they sound cool to play with, but I would hate to debug issues with them in production.
    - agentgt 11y ago
      I'm curious what you mean by debug. If you mean monitor all of our apps send metrics, health checks, and logs over the wire I'm sure that is independent. What would docker allow you over the unikernel especially given the best practice push for docker images to only run one thing in a container? IMO with Unikernel Xen aka Hypervisors are the container holders instead of docker.
      - vidarh 11y ago
        With a Docker container, I can exec into it and run strace, ltrace, gdb etc.. With a unikernel it all depends on what you have built into the unikernel. That might provide everything I need, or not. The issue is that we will need a lot of toolking to put unikernels on a sufficiently equal footing vs. being able to run decades worth of Linux tools directly in the containers.
        agentgt 11y ago
        The issue I have with that is the tooling you mention while stable and mature is actively being replaced by cloud tools because you really can't just debug a single machine in production when you have a cluster.. not to mention it is production so debug symbols might not even be available. I understand your point of the maturity w/ tooling but I see it as a serious failure if you have to log into a machine in production and run gdb or IMO any tool. Your app can and should provide healthchecks/monitoring so that you can see if there is a problem (this includes even a thread stack dump). I'm probably just biased and jaded as I have had some serious technical debt lost to Docker. It just feels like a VM on top of a VM on top of a VM of continuous things to break/learn... I want baremetal :)

thwarted 11y ago

Poettering says that PID 1 has special requirements. One of these is killing "zombie" processes that have been abandoned by their calling session. This is a real problem for Docker since the application runs as PID 1 and does not handle the zombie processes. For example, containers running the Oracle database can end up with thousands of zombie processes. Why does Poettering keep claiming this when he's the one who submitted the patch that adds the PR_SET_CHILD_SUBREAPER prctl(2) [0] functionality? [0] http://man7.org/linux/man-pages/man2/prctl.2.html http://man7.org/linux/man-pages/man2/prctl.2.html

pas 11y ago
I guess he's saying, that you can't just take any random binary and run it in a Docker container, because if that binary spawns a lot of children but does not wait for them, then you'll have a lot of zombies. Docker could run a minimal pid1 in each container to address this. Though if this had been a big issue I guess this would have been already fixed. Naturally, a proof of concept of the problem would be great. (Let's say a Dockerfile.)
- atemerev 11y ago
  Supervisord is the officially blessed solution: https://docs.docker.com/engine/admin/using_supervisord/ https://docs.docker.com/engine/admin/using_supervisord/
  - masklinn 11y ago
    supervisord specifically documents that it's not an init and shouldn't be used as an init, that's the second paragraph of its home page: http://supervisord.org/index.html?highlight=init http://supervisord.org/index.html?highlight=init
  - DannoHung 11y ago
    That is literally not at all what that is suggesting.
- vidarh 11y ago

atemerev 11y ago

I don't always run containerized applications, but when I do, I prefer them completely systemd-free, thank you. Sometimes I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels — anything, just anything without this abomination.

bryanlarsen 11y ago
Can you explain your position to me? I can understand somebody who dislikes systemd and dislikes docker. I can understand somebody who likes both systemd and docker. But disliking systemd but liking docker? That I don't understand. Any effective criticism of systemd that I've heard generally can also be applied to docker. Like yours: "I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels" works even better if you replace systemd with docker.
- atemerev 11y ago
  Docker is just a toolkit for composing and networking layered OS images. It improves isolation of things and adheres to simple principles (immutable containers, restarting instead attempting to recover, etc.) It structures things better. Inter-container communication is deliberately simple (env variables and, recently, networking). Systemd spits on isolation, it embraces integration of everything. Supervision, logging, communication, IO, configuration, state management — everything goes through systemd. Everything is binary and opaque. Docker is transparent.
  - bryanlarsen 11y ago
    Your criticism of systemd still applies to docker. "Supervision, logging, communication, IO, configuration, state management — everything goes through docker" If I use systemd I have to type 'systemd logs' to get at my logs, or I can use a plugin to move it somewhere else. If I use docker I have to type 'docker logs', or I can use a plugin to move it somewhere else. etc. etc. P.S. Agree completely with your praise of Docker. I'm firmly in the 'love both systemd and docker and wish they got along' camp.

js2 11y ago

One of these is killing "zombie" processes that have been abandoned by their calling session. That's funny terminolgy, isn't it? Killing a process usually means sending it a signal, typically TERM or KILL, that causes it to exit. But a zombie process is one that has already exited, but hasn't been waited for by its parent, where its parent is either the process that spawned it, or if that process has died, the process with PID 1. This is usually referred to as reaping the zombie process, not killing it. AFAIK, a signal sent to a zombie process is simply ignored. Or do the quotes around zombie imply a different meaning, such as "zombie-like"?

masklinn 11y ago
No, it's a zombie in the normal sense, the killing here is not sending it a signal but reaping zombie processes (in the sense of personified death reaping souls) by waiting on it. Things would probably be clearer if the quotes were around "killing" rather than "zombie", mayhaps the interviewer/writer was unfamiliar with the terminology.
- ibotty 11y ago
  I strongly doubt that! Josh knows the terminology. It was surly just an oversight.
ChrisArgyle 11y ago
If we're being technical the author should have wrote "reaping" not "killing". It's a very different process. The use of quotes is probably an acknowledgement that the term "zombie" is not universal. For example Linux uses "defunct" instead. Basically, zombie processes happen when a child process exits but the parent process--the one that spawned it--doesn't reap it. [1] [1] https://en.wikipedia.org/wiki/Zombie_process https://en.wikipedia.org/wiki/Zombie_process

storrgie 11y ago

why not systemd-nspawn (zoidberg voice) Seems like the way Fedora is packaging systemd for 24 is going to move systemd-nspawn to a level of maturity that will likely surpass some of the clunky issues folks have with running docker.