Typically, in reasonably complex programs we want to realease various
caches (such as glibc allocation caches) in case of memory pressure.
Let's add explicit infrastructure for that to sd-event, that can hook
Linux' Pressure Stall Information (PSI) logic with our event loop.
This adds sd_event_add_memory_pressure() as easy, one-step API to
install an even source that is called under memory pressure.
The parameters which file to watch (the per-cgroup PSI file, or the
system-wide file /proc/pressure/memory) can be configured via env vars.
The idea is that the service manager sooner or later gains controls for
setting this up correctly.
Alternatively to the PSI a similar logic is supported but instead of
waiting for POLLPRI on a procfs/cgroupfs fd we'll wait for POLLIN on
FIFO or AF_UNIX sockets. This is useful for testing, and possibly in
other environments, for example to hook up this protocol directly with
GNOME's low memory monitor.
By default this watches on the cgroup-local PSI so that we aren't
affected by pressure on cgroups we are not related to.
We should be more careful with distinguishing the cases "all bits set in
caps mask" from "cap mask invalid". We so far mostly used UINT64_MAX for
both, which is not correct though (as it would mean
AmbientCapabilities=~0 followed by AmbientCapabilities=0) would result
in capability 63 to be set (which we don't really allow, since that
means unset).
The rest of our codebase stores caps masks in a uint64_t, and also
assumes UINT64_MAX was a suitable value for "unset mask". Hence refuse
any caps outside of 0…62.
(right now the kernel knows 40 caps, hence 22 more to go before we have
to reconsider our life's choices.)
We refuse it otherwise currently, simply because we cannot store it in a
uint64_t caps mask value anymore while retaining the ability to use
UINT64_MAX as "unset" marker.
The check actually was in place already, just one off.
This substantially reworks mempool_cleanup() so that it releases pools
with all freed tiles only, but keeps all pools with still-allocated
tiles around.
This is more correct, as the previous implementation just released all
pools regardless if anything was still used or not. This would make
valgrind shut up but would just hide memory leaks altogether. Moreover
if called during regular runtime of a program would result in bad memory
accesses all over.
Hence, let's add a proper implementation and only trim pools we really
know are empty.
This way we can safely call these functions later, when under memory
pressure, at any time.
To match how we usually do this current allocation code.
(Also, make it accept a NULL pointer, also in order to match behaviour
in the rest of our codebase)
Follow-up for 4453ebe4db.
With the feature list all dandified, the most important part of the
output, i.e. the project name and version, are less visible.
From a given cgroup path, cg_path_get_unit() allows to retrieve the
unit's name. Although, this removes the path to the unit's cgroup,
preventing the result to be used to fetch xattrs.
Introduce cg_path_get_unit_path() which provides the path to the unit's
cgroup. This function behave similarly to cg_path_get_unit() (checking
the validity and escaping the unit's name).
- Whether we should return an absolute path or not is irrelevant
to whether CHASE_AT_RESOLVE_IN_ROOT is set. We should only return
an absolute path if we are provided one and the directory file
descriptor is AT_FDCWD
- When the directory file descriptor is AT_FDCWD, we should always
resolve symlinks against "/". Currently, if the directory file
descriptor is AT_FDCWD and CHASE_AT_RESOLVE_IN_ROOT is set, we
resolve symlinks against the current working directory which is
almost always not going to be what the caller wants.
- Currently, if we provide an absolute path with a positive directory
file descriptor without CHASE_AT_RESOLVE_IN_ROOT SET, we interpret
the path relative to "/" instead of the given directory file descriptor.
Let's make sure that when we're given a positive directory file
descriptor, we always resolve the given path relative to it.
Our logging uses program_invocation_short_name. Without this patch,
logs from forked client may become broken; spuriously truncated or
the short invocation name is not completely shown in the log.
Config options are -Ddefault-timeout-sec= and -Ddefault-user-timeout-sec=.
Existing -Dupdate-helper-user-timeout= is renamed to -Dupdate-helper-user-timeout-sec=
for consistency. All three options take an integer value in seconds. The
renaming and type-change of the option is a small compat break, but it's just
at compile time and result in a clear error message. I also doubt that anyone was
actually using the option.
This commit separates the user manager timeouts, but keeps them unchanged at 90 s.
The timeout for the user manager is set to 4/3*user-timeout, which means that it
is still 120 s.
Fedora wants to experiment with lower timeouts, but doing this via a patch would
be annoying and more work than necessary. Let's make this easy to configure.
This allows sysusers to operate with --root that is an empty directory.
It may be useful to, for example, populate the user database before installing
anything else.
firstboot was already doing this, so drop the duplicated call there.