Systemd vs. Docker

> > What design principle does Docker break by being a daemon and using a client-server architecture?
> It breaks the UNIX principle that *something* needs to reap unowned children and send SIGCHLD to living parents. Due to the way process hierarchies work and Docker's running the app/entrypoint as PID 1 in the namespace, it's broken, unless that app/entrypoint brings its own reaper functionality, which is outside the purview of applications.

This is completely unrelated to client-server architecture, so you're not answering my question, but I'll address your comment anyway. Requiring that the image provide the pid1 command was a conscious tradeoff.

On the one hand, docker could bundle its own lightweight init to reap orphans as you describe. That would work perfectly for 90% of applications because, as you point out, app developers are typically not concerned with this functionality at all. But this would make life very, very difficult for the remaining 10% which want to bundle their own init process in the image. At the top of that list, of course, is the systemd community which is adamant that the only good way to run any container is with systemd inside (see the article above). Although I personally disagree with that opinion, the whole point of Docker was to allow running anything inside a container, including a custom init.

So the other option was to run the image-specified command as pid1. This solves the problem of bringing your own custom init (although as we later found out, it takes a LOT more to make systemd happy inside a container...). It does introduce a few issues for the 90% of applications which don't require a custom init: first, an application which forks huge numbers of short-lived processes may eventually cause trouble on the system by leaving too may unreaped orphans. second, most applications only handle a minimal set of signals, so you can't communicate with them with the full spectrum of signals typically handled by an init process. The most typical example of this is that containers running a shell script as an entrypoint can only be terminated with SIGKILL, which means that 'docker stop' will hang for a few seconds of grace period. In practice this has proven to be a very minor issue: either users aren't affected at all, or they care enough and simply add an init process to their images, which solves the problem.

We could change the behavior now to insert a lightweight pid1 by default, and allow a custom field to request a custom pid1. But that would break many existing users who rely on the current behavior. Keep in mind that Docker was adopted incredibly quickly, so interface stability became an issue before we had much time to work out these issues.

I hope this helps understand our technical choices better.

> Really, really stupid oversight by Docker, although typical of their mindset of only contemplating the simple and easy.

A strong choice of words. If you have evidence to back your claim that we "only contemplate the simple and easy", feel free to share it, it would give me an opportunity to rebuke. As it stands there is really nothing more I can answer.

> I think that has far more to do with RH actually understanding operating systems and Docker only caring about its niche. Docker plays fast and loose with everything, and it's no wonder that there's a lot of friction when people who have well-designed systems try to work with something crafted from soda crackers and spaghetti.

Again, a lot of strong opinions, but no evidence to back it up.

> > Since the business of Red Hat is based on end-to-end platform lock-in, most of their patches focus on breaking that portability in some way. Invariably those patches get refused with clear and respectful feedback. Invariably the feedback is ignored and a similar patch re-opened the next day. It's a weird war of attrition, and I can't blame Jess for being tired of it.

> Wow, just wow. It's difficult to take anyone in the Docker project seriously when they spout nonsense like this

I suppose what you meant to say was "I disagree"? Anyway, here is an article which describes the strategy in more detail https://gigaom.com/2014/05/13/is-red-hat-the-new-oracle/

Selected quote: "Red Hat — which makes its money selling support and maintenance for its open-source products — [will] refuse to support of users of Red Hat Enterprise Linux who also run non-Red Hat versions of OpenStack. [...] that could ding OpenStack’s promise of no-vendor-lock-in."

> although I suppose the quality of their product already says plenty.

More strong opinions without evidence to back it up.

> It's Docker that tries to lock people in and goes out of its way not to cooperate with other tools and projects.

I'm not sure you understand what "lock-in" means... Do you have any evidence whatsoever that Docker - an open-source tool whose primary feature is portability and independence of the operating system and hardware - is contributing to lock-in?

Same question on going out of our way not to cooperate. What is your evidence? I wish you at least made the effort to articulate a basic argument? Otherwise it's very difficult to have a constructive conversation.

>>> According to him, Docker is working on "containerd", its new alternative to systemd, which will take over the functions of the init system.

>> This is plain wrong.

> Nope, it's just your reading comprehension. "Functions" in this sense doesn't mean all that the init system can do. Instead, it means the limited functionality that it's being used in containers.

The same article says "they dream of being systemd". In that context I think my interpretation is reasonable.