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
The existing text already said "See below regarding a recommended
vocabulary for boot loader entry identifiers.", but the section for it
was still missing. Let's fill in the missing bits, and describe basic
suggested rules for the boot menu entry identifier vocabulary, in
particular how to identify Windows and MacOS X installations, and how to
name automatic entries vs. explicitly configured ones.
This basically follows the logic implemented in sd-boot these days.
In the PAM module we need to suppress LOG_DEBUG messages manually, if
debug logging is not on, as PAM won't do this for us. We did this
correctly for most log messages already, but two were missing. Let's fix
those too.
Fixes: #10822
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.
It was only used in one place, where we don't actually need it, and
it is too easy to forget to update it when adding new items to the table.
Let's just drop it.
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.