diff options
author | Lennart Poettering <lennart@poettering.net> | 2018-10-01 17:38:48 +0200 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2018-10-16 16:33:55 +0200 |
commit | 99ab6fdf8c68bbe05a127b59ae03d2156d6ea856 (patch) | |
tree | db8e05701daeddf7deb883c29989794451da5ef7 /src/login | |
parent | d6e069f412edc02a0f2130fa47955d02e378d5f5 (diff) | |
download | systemd-99ab6fdf8c68bbe05a127b59ae03d2156d6ea856.tar.gz systemd-99ab6fdf8c68bbe05a127b59ae03d2156d6ea856.tar.bz2 systemd-99ab6fdf8c68bbe05a127b59ae03d2156d6ea856.zip |
core: add a new call for bumping RLIMIT_NOFILE to "high" values
Following discussions with some kernel folks at All Systems Go! it
appears that file descriptors are not really as expensive as they used
to be (both memory and performance-wise) and it should thus be OK to allow
programs (including unprivileged ones) to have more of them without ill
effects.
Unfortunately we can't just raise the RLIMIT_NOFILE soft limit
globally for all processes, as select() and friends can't handle fds
>= 1024, and thus unexpecting programs might fail if they accidently get
an fd outside of that range. We can however raise the hard limit, so
that programs that need a lot of fds can opt-in into getting fds beyond
the 1024 boundary, simply by bumping the soft limit to the now higher
hard limit.
This is useful for all our client code that accesses the journal, as the
journal merging logic might need a lot of fds. Let's add a unified
function for bumping the limit in a robust way.
Diffstat (limited to 'src/login')
0 files changed, 0 insertions, 0 deletions