This is to startswith() what PATH_STARTSWITH_SET() is to
path_startswith().
Or in other words, checks if the specified string has any of the listed
prefixes, and if so, returns the remainder of the string.
Unfortunately, f5f9a580dd didn't help much and now
the next subtest gets stuck from time to time. Let's skip
test-execute altogether so as not to bother anybody with
spurious failures.
https://github.com/systemd/systemd/issues/10696 is still open.
Everybody is welcome to share ideas :-)
Let's not bother contributors with spurious failures nobody can't
seem to reproduce. There is an issue about that where we're trying
to figure out what's going on: https://github.com/systemd/systemd/issues/10696.
Let's use the correct wrapper for calling unit vtable functions. Let's
make sure we always use the right wrappers, and never bypass them
needlessly.
Moreover use SIGKILL rather than "9" as signal name. Let's not be
needlessly cryptic.
Follow-up for: f7f8e8cbb9
As was shown in https://github.com/systemd/systemd/issues/10696#issuecomment-439613204,
currently `meson` waits for 1080 seconds (which is three times the global timeout) for the
test to fail completely even though it takes just two minutes for it to really fail. This
happens because the test itself leaves the services it has launched behind, which, in turn, makes
meson think that the test is still in progress. KILL_ALL with SIGKILL should make the issue
go away.
systemd only uses functions that are as of Linux 4.15+ provided
externally to the CPU controller (currently usage_usec), so if we have a
new enough kernel, we don't need to set CGROUP_MASK_CPU for
CPUAccounting=true as the CPU controller does not need to necessarily be
enabled in this case.
Part of this patch is modelled on an earlier patch by Ryutaroh Matsumoto
(see PR #9665).
This removes the ability to configure which cgroup controllers to mount
together. Instead, we'll now hardcode that "cpu" and "cpuacct" are
mounted together as well as "net_cls" and "net_prio".
The concept of mounting controllers together has no future as it does
not exist to cgroupsv2. Moreover, the current logic is systematically
broken, as revealed by the discussions in #10507. Also, we surveyed Red
Hat customers and couldn't find a single user of the concept (which
isn't particularly surprising, as it is broken...)
This reduced the (already way too complex) cgroup handling for us, since
we now know whenever we make a change to a cgroup for one controller to
which other controllers it applies.
Now that we don't (mis-)use the env file parser to parse kernel command
lines there's no need anymore to override the used newline character
set. Let's hence drop the argument and just "\n\r" always. This nicely
simplifies our code.
All users of the macro (except for one, in serialize.c), use the macro in
connection with read_line(), so they must include fileio.h. Let's not play
libc games and require multiple header file to be included for the most common
use of a function.
The removal of def.h includes is not exact. I mostly went over the commits that
switch over to use read_line() and add def.h at the same time and reverted the
addition of def.h in those files.
It was always set to one third of timeout_usec, so let's simplify things by
calculating it using a helper function right before it is used.
Before 9d9264ba39, udevd.c would avoid setting
timeout_warn_usec to 0, using 1 instead. This wasn't necessary, because when
timeout_warn_usec is finally used in spawn_wait(), it is ignored if
timeout_usec is 0 or timeout_warn_usec is 0. So there was no need to handle
this case specially.
Rename rdrand64 to rdrand, and switch from uint64_t to unsigned long.
This produces code that will compile/assemble on both x86-64 and x86-32.
This could be useful when running a 32-bit copy of systemd on a modern
Intel processor.
RDRAND is inherently arch-specific, so relying on the compiler-defined
'long' type seems reasonable.
Docker's default capability set has the inherited flag already
set - that breaks tests which expect otherwise. Let's just
drop the check and run the test anyway.
Fixes#10663
We only use this when we don't require the best randomness. The primary
usecase for this is UUID generation, as this means we don't drain
randomness from the kernel pool for them. Since UUIDs are usually not
secrets RDRAND should be goot enough for them to avoid real-life
collisions.
