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.
We now don't enable the CPU controller just for CPU accounting if we are
on 4.15+ and using pure unified hierarchy, as this is provided
externally to the CPU controller. This makes CPUAccounting=yes
essentially free, so enabling it by default when it's cheap seems like a
good idea.
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).
It's possible for sscanf to receive strings containing all three fields
and not matching the template at the same time. When this happens the
value of k doesn't change, which basically means that process_audit_string
tries to access memory randomly. Sometimes it works and sometimes it doesn't :-)
See also https://bugzilla.redhat.com/show_bug.cgi?id=1059314.
This is not obvious, hence it deserves some form of documentation.
However, it's also ultimately an implementation detail, hence let's not
add this to the man page, but as a code comment, that is visible right
at the top of source file.
Fixes: #10675
While it doesn't really make much sense to set "auto-reboot-to-firmware"
as oneshot boot item, let's still support it properly, by also
dispatching such a menu item if selected.
Let's stick to one nomenclature. In userspace we usually call this
"reboot to firmware setup", hence use the same name in sd-boot too.
This name was previously only relevant internally, but since the
addition of the LoaderEntries EFI var is exposed to userspace, hence
let's get this right with the first release adding this.
We keep adding new features, let's advertise to the host OS what these
are in a new variable LoaderFeatures.
It works a bit like OsIndicationsSupported, but is about Loader
features.