News for hackers. Stuff that matters.
Re:Introducing dumb-init, an init system for Docker containers by ckuehl on Wednesday January 06, 2016 @04:37PM (#10853992)
> From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case?

The biggest issue we see at Yelp is leaking containers in test (e.g. Jenkins aborting a job but leaving the containers it spawned still running).

Depending on how you orchestrate containers, you might not encounter the issue in prod. If you're using something like Kubernates or Marathon or Paasta, they're probably going to do the "right thing" and ensure the containers are actually stopped.

We also use containers a lot in development. For example, we might put a single tool into a container, and then when developers call that tool, they're actually spawning a container without realizing it. For this use case, it's really important that signals are handled properly so that Ctrl-C (and similar) continues working.

Re:Introducing dumb-init, an init system for Docker containers by sandGorgon on Wednesday January 06, 2016 @10:21PM (#10855760)
Why did you not use something like supervisord? I run a few containers (obviously not at yelp scale) and supervisors has been spectacular at restarting, managing,reloading,etc. It handles nginx,gunicorn,puma,tomcat, etc pretty well. Yes its python - but was that the motivation?

Also,you guys should comment on https://github.com/docker/docker/pull/5773 which is work on unprivileged systemd in docker. I think you guys can influence the bug with your experience in this.

Re:Introducing dumb-init, an init system for Docker containers by anonbanker on Wednesday January 06, 2016 @11:04PM (#10855901)
some of us don't want systemd and it's tag-alongs ruining our docker.