Public bug reported:
When systemd currently starts in a container that has RLIMIT_NOFILE set to e.g.
100000 systemd will lower it to 65536 since this value is hard-coded into
systemd.
I've pushed a patch to systemd upstream that will try to set
the nofile limit to the allowed kernel maximum. If this fails, it will compute
the minimum of the current set value (the limit that is set on the container)
and the maximum value as soft limit and the currently set maximum value as the
maximum value. This way it retains the limit set on the container.
It would be great if we could backport this patch to have system adhere to
nofile limits set for the container. This is especially important since user
namespaces will allow you to lower the limit but not raise it back up
afterwards.
The upstream patch is appended.
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "0001-main-improve-RLIMIT_NOFILE-handling-5795.patch"
https://bugs.launchpad.net/bugs/1686361/+attachment/4868175/+files/0001-main-improve-RLIMIT_NOFILE-handling-5795.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1686361
Title:
systemd does not respect nofile ulimit when running in container
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1686361/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
