3 ms·

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

23 points by sethish 11y ago

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

gepoch 11y ago
If you didn't set lxc CPU quotas then this isn't very suprising! See: http://stackoverflow.com/questions/16084741/how-do-i-set-resources-allocated-to-a-container-using-docker http://stackoverflow.com/questions/16084741/how-do-i-set-res...
- djb_hackernews 11y ago
  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 11y ago
Stick to VMs for production use, for now. With thin provisioned storage and in-memory de-dupe.
- eeZi 11y ago
  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 11y ago
    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).
thriqon 11y ago
Why shouldn't it? ssh can do the same on a remote host, yet no one complains about that ;-)
- eeZi 11y ago
  Yeah but people tend to mistake containers with VMs, and you cannot do this with VMs.
djb_hackernews 11y ago
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.

23 points by sethish 11y ago

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-resources-allocated-to-a-container-using-docker http://stackoverflow.com/questions/16084741/how-do-i-set-res...

djb_hackernews 11y ago
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 11y ago

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

eeZi 11y ago
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 11y ago
  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).

thriqon 11y ago

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

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

djb_hackernews 11y ago

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.