This updates the unit files of all our serviecs that deal with journal
stuff to use a higher RLIMIT_NOFILE soft limit by default. The new value
is the same as used for the new HIGH_RLIMIT_NOFILE we just added.
With this we ensure all code that access the journal has higher
RLIMIT_NOFILE. The code that runs as daemon via the unit files, the code
that is run from the user's command line via C code internal to the
relevant tools. In some cases this means we'll redundantly bump the
limits as there are tools run both from the command line and as service.
Following the discussions with the kernel folks, let's substantially
increase the hard limit (but not the soft limit) of RLIMIT_NOFILE to
256K for all services we start.
Note that PID 1 itself bumps the limit even further, to the max the
kernel allows. We can deal with that after all.
This makes use of rlimit_nofile_bump() in all tools that access the
journal. In some cases this replaces older code to achieve this, and
others we add it in where it was missing.
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.
This simply adds a new constant we can use for bumping RLIMIT_NOFILE to
a "high" value. It default to 256K for now, which is pretty high, but
smaller than the kernel built-in limit of 1M.
Previously, some tools that needed a higher RLIMIT_NOFILE bumped it to
16K. This new define goes substantially higher than this, following the
discussion with the kernel folks.
Let's split exit code handling in two: "r" is only used for errno-style
errors, and "ret" is used for exit() codes. Then, let's use EXIT_SUCCESS
for checking whether the latter is already used.
This way it should always be clear what kind of error we are processing,
and when we propaate one into the other.
Moreover this allows us to drop "q" form all inner loops, avoiding
confusion when to use "q" and when "r" to store received errors.
Fixes: #9704
Let's be safe than sorry, in particular as logind doesn't set it up
anymore, but user-runtime-dir@.service does, and logind doesn't really
track success of that.
So far we always used "yes" instead of "true" in all our unit files,
except for one outlier. Let's do this here too. No change in behaviour
whatsoever, except that it looks prettier ;-)
This heavily borrows from @intelfx' PR #5546, but watches all three
units that are associated with a user now: the slice, the user@.service
and user-runtime-dir@.service.
The logic and reasoning behind it is the same though: there's no value
in keeping lingering users around if all their three services are gone.
Replaces: #5546Fixes: #4162
Let's make this a bit prettier, and propagate unexpected access() errors
correctly.
(The callers of this function will suppress them, but it's nicer of they
do that, rather than us doing that twice in both the callers and the
callees)
This is useful so that during shutdown scope units are always terminated
before the mounts necessary for the home directory.
(Ideally we'd also add a similar dependency from the user@.service
instance to the home directory, but this isn't as easy as that service
is defined statically and not dynamically, and hence not easy to modify
dynamically, in particular when it comes to deps)
I think this is a slightly cleaner approach than parsing the
configuration file at multiple places, as this way there's only a single
reload cycle for logind.conf, and that's systemd-logind.service's
runtime.
This means that logind and dbus become a requirement of
user-runtime-dir, but given that XDG_RUNTIME_DIR is not set anyway
without logind and dbus around this isn't really any limitation.
This also simplifies linking a bit as this means user-runtime-dir
doesn't have to link against any code of logind itself.
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Harry Mallon
Yu Watanabe
Ben Boeckel