Hello Christian, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu19 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Tags removed: verification-done verification-done-xenial ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1686361 Title: systemd does not respect nofile ulimit when running in container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Yakkety: In Progress Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Bug description: [Impact] * Containers cannot use maximum RLIMIT_NOFILE, because systemd sets an arbitrary cap. [Test Case] * Start container with high RLIMIT_NOFILE (e.g. 100 000) * Check that RLIMIT_NOFILE on the container is more than 65536 [Regression Potential] * This is a feature / change of behaviour. Some users may be relying on the lower RLIMIT_NOFILE cap, but it should not have a negative impact on the host (as in creating too many file descriptors/denial of service). [Original Bug Report] 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1686361/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp