file-hierarchy does not mention anything about the expected mountpoint
for cgroups. This may lead some software to believe it will need to
search for it (e.g. by scanning mountinfo) rather than just looking in
the canonical location.
Document the canonical mountpoint as /sys/fs/cgroup. Also provide
information on the non-default configurations, but
make it clear that in such configurations if cgroup2 is mounted (hybrid
mode) it won't have resource controllers attached. This will help
software know if it should fall back to /sys/fs/cgroup/unified or just
ignore that case.
Python gained support for reading os-release, let's advertise it a bit more.
Our open-coded example is still useful, but let's not suggest it as the
default implementation.
I added quotes around the printed string because it looks a bit better
this way.
It turns out we can't have an Example nested in a list, and every
combination of nesting I tried looked bad either in troff or in html.
The whole example is moved to a separate section.
glibc now has Suggests:glibc-minimal-langpack, so we don't
need to mention it ourselves.
--repo=… is a nicer alternative to --disablerepo=* --enablerepo=….
It also avoids the issue with quoting.
Let's exclude weak deps, but install systemd-networkd, so the container
can configure networking if necessary.
Add support for managing and configuring watchdog pretimeout values if
the watchdog hardware supports it. The ping interval is adjusted to
account for a pretimeout so that it will still ping at half the timeout
interval before a pretimeout event would be triggered. By default the
pretimeout defaults to 0s or disabled.
The RuntimeWatchdogPreSec config option is added to allow the pretimeout
to be specified (similar to RuntimeWatchdogSec). The
RuntimeWatchdogPreUSec dbus property is added to override the pretimeout
value at runtime (similar to RuntimeWatchdogUSec). Setting the
pretimeout to 0s will disable the pretimeout.
We expose various other forms of UUID helpers already, i.e.
SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR(), and we parse
UUIDs, hence add a high-level helper for formatting UUIDs too.
This doesn't add any new code, it just moves some helpers
id128-util.[ch] → sd-id128.[ch], to make them public.
Add the "Isolated" parameter in the *.network file, e.g.,
[Bridge]
Isolated=true|false
When the Isolated parameter is true, traffic coming out of this port
will only be forward to other ports whose Isolated parameter is false.
When Isolated is not specified, the port uses the kernel default
setting (false).
The "Isolated" parameter was introduced in Linux 4.19.
See man bridge(8) for more details.
But even though the kernel and bridge/iproute2 recognize the "Isolated"
parameter, systemd-networkd did not have a way to set it.
In D-Bus, clients connect to a bus (the usual case), or use direct
questions to each other (the unusual case). A bus is a program one can
connect to and implemented by dbus-daemon or dbus-broker. HOwever,
busses never connect between each other, that doesn't exist. Hence don't
claim so.
This is probably confusion about the fact that sd-bus calls D-Bus
connection objects just "sd_bus" for simplicity, given they are used in
99% of the cases to connect to a bus — only in exceptional cases they
are used for direct connections between peers without involving a bus.
Follow-up for b7bb58ef70
Since a long time the D-Bus spec knows a special bit in its message
header for indicating that "interactive" authentication is OK. The
original hostnamed API is before that was added hence most functions
expose that boolean as explicit argument.
For new added functions let's get rid of it, the message flag is good
enough and replaces it with complete functionality.
No new APIs should carry the "interactive" boolean flag explicitly as
argument anymore.
Follow-up for: 9697662915
The general approach of kernel-install was that each plugin would drop in some
files into the entry directory. But this doesn't scale well, because if we have
multiple initrd generators, or multiple initrds, each generator would need to
recreate the logic to put the generated files in the right place.
Also, effective cleanup is impossible if anything goes wrong on the way, so we
could end up with unused files in $BOOT.
So let's invert the process: plugins drop files into $KERNEL_INSTALL_STAGING_AREA,
and at the end 90-loaderentry.install DTRT with those files.
This allow new plugins like 50-mkosi-initrd.install to be significantly simpler.
