Live data from Hacker News

Systemd vs. Docker

lwn.net

11–20 of 97 posts

Re: Systemd vs. Docker

#11
post #3

Earlier quoted context omitted.

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

Or they can move to one of the BSDs and use jails which are much more stable, secure, and tested than linux containers.

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

Re: Systemd vs. Docker

#12

Earlier quoted context omitted.

Or they can move to one of the BSDs and use jails which are much more stable, secure, and tested than linux containers.

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.

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

Re: Systemd vs. Docker

#13
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

Re: Systemd vs. Docker

#14
post #8

Earlier quoted context omitted.

Or they can move to one of the BSDs and use jails which are much more stable, secure, and tested than linux containers.

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 repli…

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.

Re: Systemd vs. Docker

#15
post #3

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

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

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.

Re: Systemd vs. Docker

#16

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 s…

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

Re: Systemd vs. Docker

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

Re: Systemd vs. Docker

#18

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 s…

That doesn't have anything to do with Poettering's quote.

PR_SET_CHILD_SUBREAPER moves the ownership of an orphaned process to whichever process was selected rather than the default PID1, and that only works for descendant of the subreaper.

The problem pointed by the quote is that normal software doesn't go around checking if it has zombie children and waiting on them, so in a container with random software S set as PID1 and creating subprocesses, zombies may accumulate until resources are exhausted[0].

PR_SET_CHILD_SUBREAPER is a way to cause that problem on a system with a proper init (or to test that your init works properly without needing to boot into it)

It's not a new observation: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...

Previous HN discussion: https://news.ycombinator.com/item?id=8916785

[0] by default the limit is 32k processes after which the kernel will simply refuse to create new ones

Re: Systemd vs. Docker

#19
post #10
post #7

Earlier quoted context omitted.

I really hope unikernels take off because I really hate dealing with both (particularly docker more so than systemd).

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.

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.

Re: Systemd vs. Docker

#20

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

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?

Opinionated, yes. Monolithic, no. Huge mess of everything that deeply integrates in any system — of course not, your containers don't need to know anything about Docker and host system, you are absolutely free in choices. It's even possible to run (gasp!) multiple services with supervision inside Docker.
Post reply on HN