Description of problem: On newer releases, we might want to set a TasksMax value in docker.service, so that the daemon doesn't get an EAGAIN when it's trying to start things. TasksMax=infinity works for me, but I haven't worked through the implications. Version-Release number of selected component (if applicable): docker-1.10.2-5.git0f5ac89.fc24.x86_64 on kernel-4.5.0-0.rc2.git2.1.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. docker run -d --name porttest -p 3800-3900:3800-3900 busybox top Actual results: Docker returns a failure because it couldn't start that many docker-proxy processes. Expected results: Success! Or rather, lack of an error. Additional info: This also causes DockerSuite.TestPsGroupPortRange in the docker integration test suite to fail.
jerms, wdyt?
What is the default tasksmax?
This is messy, we just last week got the pids cgroup controller backported into RHEL (it's in 3.10.0-372) via https://bugzilla.redhat.com/show_bug.cgi?id=1265339). But the whole point of that controller is to protect from a fork bomb inside a container, and if we set TasksMax=infinity we effectively disable the fork bomb detection that we were after in the first place. So, unless I'm reading it wrong, no, I would not recommend touching TasksMax. It also implicitly enables taskaccounting all the way up the cgroup structure. This needs more thought and testing before we touch it. As far as preventing the EAGAIN, I haven't seen an strace so I'm not sure where that's coming from -- is it from the kernel/iptables? Anyway we're not using the docker-proxy anywhere in openshift or atomic, we use the kube-proxy, and soon we will likely be offering at least an option to use iptables. Again, unless I'm not following -- I can't see how mapping 1000 ports in a userspace app like docker-proxy is a use-case we should be all too concerned with. If you really need 1000 ports, what about --net=host ?
And now I see this is a Fedora request, so disregard the kernel version stuff. wrt the fork bomb. If you look at systemd-system.conf upstream there is: src/core/system.conf:#DefaultTasksMax=512 src/login/logind.conf:#UserTasksMax=12288 units/systemd-nspawn@.service.in:TasksMax=8192 So, default is 512 and nspawn service gets 8k. I guess that's more reasonable than infinity. So you want to set TasksMax=8192 for docker.service ?
Since container processes end up in a different Cgroup they are not a problem. We can set this to 8192, but you were concerned about this having a performance hit, correct? If not performance hit then setting thit so nspawns, default is justifiable.
I am concerned about the accounting stuff because it's never been tested. Unless someone magic's up some data asap, we're going to enable taskaccounting in openshift anyway: My POV is here: https://github.com/openshift/origin/pull/8989#issuecomment-221939970 As far as tasksmax...wasn't that part of the other BZ... https://bugzilla.redhat.com/show_bug.cgi?id=1340519
actually its the cpu/mem accounting. sigh, long week...
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Lokesh/Antonio, I see TaskMasks=Infinity in Rawhide, but Jeremy recommended 8192 TasksMax=8192 Could we change to that default.
Changed to 8192 in both F25 and Rawhide
docker-1.12.1-4.git8ea583f.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e7176b9785
docker-1.12.1-4.git8ea583f.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e7176b9785
docker-1.12.1-5.git8ea583f.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ffeefb3138
docker-1.12.1-5.git8ea583f.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ffeefb3138
docker-1.12.1-6.git49151a1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-626f41754c
docker-1.12.1-6.git49151a1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-626f41754c
docker-1.12.1-7.git49151a1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-7e3f838986
docker-1.12.1-7.git49151a1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7e3f838986
docker-1.12.1-8.gitf1040da.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-caa6a905c5
docker-1.12.1-8.gitf1040da.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-caa6a905c5
docker-1.12.1-8.gitf1040da.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.