Docker can forkbomb the host system: `docker run busybox “:(){ :|:& };:”` | Hacker News Reader

Docker can forkbomb the host system: `docker run busybox “:(){ :|:& };:”`

23 pointssethish8 comments

I didn't expect this to to be able to lock up my machine :-S.

If you didn't set lxc CPU quotas then this isn't very suprising!

See: http://stackoverflow.com/questions/16084741/how-do-i-set-res...

That information is quite out of date as docker doesn't use lxc as it's execution driver by default. This explains how to control cgroups with docker https://docs.docker.com/engine/reference/run/

Stick to VMs for production use, for now. With thin provisioned storage and in-memory de-dupe.

This. Containers are not ready for production, except for fault-tolerant/distributed payloads. You can't even live migrate them to another host, and CRIU is nowhere near production ready (assuming it ever will be).

Everything else? VMs it is. The overhead is so low nowadays that it's totally irrelevant for the vast majority of use cases.

Sorry everyone's downvoted you, despite that you're correct.

I do Devops, and Docker provides very little benefit in production (unless you're an org with your own non-cloud computing resources, where you're going to orchestrate with something like Kubernetes; even then, there's dissent in the ranks between that project and Docker).

Not sure if I am missing something but this shouldn't be all that surprising. The process you execute in the container is being handled by the same kernel as the host. I think this is a common fundamental misunderstanding of what docker is. If it's a fork bomb on your host (and this is) it's a fork bomb with docker too.

Now the interesting thing about docker is you can control this in similar ways you'd do to control this via VMs and that is via kernel primitives (cgroups) to control resource allocation. In general if you are running docker containers in production you should be explicitly allocating resources via cgroups according to the needs of your applications. If you are writing and deploying software that fork bombs (why?) then you should mitigate the effects of the noisy neighbor via the kernel features. The benefit here is you don't need the (extremely, IMO) heavyweight overhead of running separate OSes in VMs.

Why shouldn't it? ssh can do the same on a remote host, yet no one complains about that ;-)

Yeah but people tend to mistake containers with VMs, and you cannot do this with VMs.

Reply on news.ycombinator.com