Bug#865449: src:systemd: LimitNOFILE does not work as advertised

[Hilko Bengen]

Source: systemd
Version: 232-25
Severity: important
Tags: patch stretch fixed-upstream

Dear Maintainers,

I recently tried to tune the RLIMIT_NOFILE value for a service requiring
more than the default 4096 open file descriptors by adding
/etc/systemd/system/$SERVICE.d/override.conf files:

,----
| [Service]
| LimitNOFILE=300000
`----

After restarting the service, I checked /proc/$PID/limits of the
processes belonging to the service and found that, indeed, the "Max open
files" line had been changed from the previous values 1024/4096 (soft
limit/hard limit). However, the limits had only been raised to
65536/65536.

I found that a similar-looking problem has been reported in Ubuntu as
<https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1686361> and
that a patch for this has been accepted upstream:

,----
| commit 25ad0e0c1119411b10c314771824569d895a7df4
| Author: Christian Brauner <christian.brauner at ubuntu.com>
| Date:   Wed Apr 26 06:18:10 2017 +0200
| 
|     main: improve RLIMIT_NOFILE handling (#5795)
| 
|     This has systemd look at /proc/sys/fs/nr_open to find the current maximum of
|     open files compiled into the kernel and tries to set the RLIMIT_NOFILE max to
|     it. This has the advantage the value chosen as limit is less arbitrary and also
|     improves the behavior of systemd in containers that have an rlimit set: When
|     systemd currently starts in a container that has RLIMIT_NOFILE set to e.g.
|     100000 systemd will lower it to 65536. With this patch systemd 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.
`----

My tests (rebuild systemd/232-25 with this patch applied, install into
an otherwise clean VM running stretch, systemctl reexec-daemon,
systemctl restart $SERVICE, inspect /proc/$PID/limits) show that this
patch solves the problem for me.

Please consider including the patch and updating systemd for a stretch
point release. Thank you.

Cheers,
-Hilko