Conversation
github-actions
bot
added
6.topic: nixos
|
This has to be backported to 23.11 |
for the second time, somebody thought setting the NOFILE limit to `infinity` was a good idea, which breaks a whole lot of systems. I can’t easily remove the option like the upstream change does, so for now it sets it to the high-but-bounded number as proposed in the original PR. We are gonna have to remove once the merged PR lands.
Profpatsch
force-pushed
the
docker-fix-nofile-limit
branch
from
d17640f to
9e93abb
Compare
ofborg
bot
added
10.rebuild-darwin: 0
| # Fix from https://github.com/containerd/containerd/pull/4475 | ||
| # (see also https://github.com/containerd/containerd/pull/7566 ) | ||
| # Setting this to infinity breaks e.g. cupsd inside docker | ||
| # So we reset to the default value. | ||
| LimitNOFILE = 1048576; |
There was a problem hiding this comment.
LimitNOFILE=1048576 isn't the default in systemd.
LimitNOFILE=1024:524288 is. Which in turn translates to LimitNOFILE=524288 and LimitNOFILESoft=1024.
The fix containerd and moby/moby eventually settled on isn't to set it back to 1048576 (which it was before someone set it to infinity).
Instead, they both unset that line, resulting in systemd's default value (1024:524288).
And the fixed openrc and sysvinit service files in went with 524288 as well.
We could also just remove the offending line from the unit file in our docker_24 package instead of the nixos/docker module.
Especially given this will be resolved with docker_25, because moby/moby#45534 has been merged already and is even part of the current release candidates.
Speaking of docker_25, #278607 carries a patch to set LimitNOFILE=1048576 for nixos/docker as well.
I don't see why we would want to restore the previous LimitNOFILE=1048576 behavior.
The reasoning and history outlines in the opening comment moby/moby#45534 (comment) sounds... well... reasonable to me.
I would much rather prefer fixing this in our docker_24 package, instead of the module.
- If we go with
LimitNOFILE=1048576in the module, we are stuck with non-default legacy behavior. - If we go with
LimitNOFILE=1024:524288in the module, we override the out-of-the-box value fordocker_20_10. - If we remove the
LimitNOFILE=infinityfrom${docker_24}/etc/systemd/system/docker.service, we fix and solve the upstream bug and don't influence the value ofdocker_20_10and the upcomingdocker_25.
2 participants
for the second time, somebody thought setting the NOFILE limit to
infinitywas a good idea, which breaks a whole lot of systems.I can’t easily remove the option like the upstream change does, so for now it sets it to the high-but-bounded number as proposed in the original PR. We are gonna have to remove once the merged PR lands.
Description of changes
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.