
Docker can forkbomb the host system: `docker run busybox “:(){ :|:& };:”` - sethish
I didn&#x27;t expect this to to be able to lock up my machine :-S.
======
gepoch
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...](http://stackoverflow.com/questions/16084741/how-do-i-set-resources-
allocated-to-a-container-using-docker)

~~~
djb_hackernews
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/](https://docs.docker.com/engine/reference/run/)

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

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

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

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

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

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

