I open sourced docker-salt, a small project for spinning up a full SaltStack environment (one master, an army of minions) entirely in Docker. The interesting question: what happens when you actually try to run 100 minions on a 16 GB server?

docker run -d --hostname saltmaster --name saltmaster \
  -v `pwd`/srv/salt:/srv/salt \
  -p 8000:8000 -ti mbologna/saltstack-master

for i in {1..100}; do
  docker run -d \
    --hostname saltminion$i \
    --name saltminion$i \
    --link saltmaster:salt \
    mbologna/saltstack-minion
done

Around the 50th container, Docker refuses to start new ones:

docker: Error response from daemon: containerd: container not started.
docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:237: starting init process command caused \\\"fork/exec /proc/self/exe: resource temporarily unavailable\\\"\"\n".

The containerd logs are more specific:

containerd[2072]: time="2017-04-20T22:59:10Z" level=error msg="containerd: start container" error="oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:243: running exec setns process for init caused \\\"exit status 6\\\"\"\n"

Root cause Link to heading

cgroups impose a limit on the number of tasks (processes/threads) a service can create. By default, systemd sets a TasksMax on the containerd service unit, which limits how many processes it can fork. When you hit that limit, no new containers can start; each container requires a new process.

Fix Link to heading

Open the containerd systemd unit file:

/usr/lib/systemd/system/containerd.service

In the [Service] section, add:

[Service]
TasksMax=infinity

Then reload and restart:

systemctl daemon-reload
systemctl restart containerd

After this, Docker can start all 100 minions without hitting the limit.

Updated 2026: Modern Docker and containerd installations often set TasksMax=infinity by default, or use cgroups v2 with different accounting. If you’re hitting container startup failures related to resource limits, the first thing to check is systemctl show containerd | grep TasksMax and the containerd journal. The fix is the same; the specific default value may vary by distribution and version.