This new setting allows configuration of CFS period on the CPU cgroup, instead
of using a hardcoded default of 100ms.
Tested:
- Legacy cgroup + Unified cgroup
- systemctl set-property
- systemctl show
- Confirmed that the cgroup settings (such as cpu.cfs_period_ns) were set
appropriately, including updating the CPU quota (cpu.cfs_quota_ns) when
CPUQuotaPeriodSec= is updated.
- Checked that clamping works properly when either period or (quota * period)
are below the resolution of 1ms, or if period is above the max of 1s.
This works like parse_sec() but defaults to USEC_INFINITY when passed an
empty string or only whitespace.
Also introduce config_parse_sec_def_infinity, which can be used to parse
config options using this function.
This is useful for time options that use "infinity" for default and that
can be reset by unsetting them.
Introduce a test case to ensure it works as expected.
As device units will be reloaded by systemd whenever the corresponding device generates a "changed" event, if the mount unit / cryptsetup service is wanted by its device unit, the former can be restarted by systemd unexpectedly after the user stopped them explicitly. It is not sensible at all and can be considered dangerous. Neither is the behaviour conventional (as `auto` in fstab should only affect behaviour on boot and `mount -a`) or ever documented at all (not even in systemd, see systemd.mount(5) and crypttab(5)).
dbus-daemon might have a slightly different idea of what a valid msg is
than us (for example regarding valid msg and field sizes). Let's hence
try to proceed if we can and thus drop messages rather than fail the
connection if we fail to validate a message.
Hopefully the differences in what is considered valid are not visible
for real-life usecases, but are specific to exploit attempts only.
Devices like the "Microsoft Microsoft® 2.4GHz Transceiver v9.0 Mouse" contain
characters higher than 127. That ® is correctly stored in the hwdb and passed
into the search field during query, but the comparison fails.
Our search string is a const char *, trie_string() returns a const char * but
the current character is cast to uint8_t. This causes anything over 127 to
fail the match. Fix this, we're dealing with characters everywhere here after
all.
We should probably refer to them from other man pages
for programs which use them, since right now all refs are
in systemd-boot(7). But creating the section is a good step
anyway.
They is quite a bit of those directives and they were in "MISCELLANEOUS" because
they don't quite fit anywhere. When the OCI-compat stuff is merged, there'll
be even more, so let's make a separate section for them.
We had "SYSTEM MANAGER DIRECTIVES" which was a misnomer already, because
it also listed user manager stuff. Let's make this a more general section
and move the items for other services there too (from "MISCELANENOUS").
Strictly speaking, those are not environment variables, but they are compatible
and people think about them like this. Moving them makes them easier to find.
The original version of the test used netcat along with a standard
AF_UNIX socket, which caused issues across different netcat
implementations. The AF_UNIX socket was then replaced by a FIFO with a
simple echo, which, however, suffers from the same issue (some echo
implementations don't check if the write() was successful).
Let's revert back to the AF_UNIX socket, but replace netcat with socat,
which, hopefully, resolves the main issue.
Relevant commit: 9b45c2bf02
Fixes#11600.
The code was effectively doing:
json_build(..., ({ char **_x = ((char**) ((const char*[]) {"one", "two", "three", "four", NULL })); _x; }));
but there was no guarantee that the storage for the array that _x points to
survives pass the end of the block. Essentially, STRV_MAKE cannot be used
inline inside of a block like this.
Yu Watanabe
Filipe Brandenburger
Tom Yan
Susant Sahani
Evgeny Vereshchagin
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Peter Hutterer
Frantisek Sumsal
Alberts Muktupāvels
Stephan E
Lance
Stephan Gerhold