The attachment "0001-main-improve-RLIMIT_NOFILE-handling-5795.patch"
seems to be a patch.  If it isn't, please remove the "patch" flag from
the attachment, remove the "patch" tag, and if you are a member of the
~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

-- 
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:
  Confirmed
Status in systemd source package in Xenial:
  New
Status in systemd source package in Yakkety:
  New
Status in systemd source package in Zesty:
  New
Status in systemd source package in Artful:
  Confirmed

Bug description:
  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

Reply via email to