tmpfiles might be linking the configuration for ldconfig into /etc
so make sure it runs after it so that the configuration is guaranteed
to be in place.
Different device paths may resolve to same device node
(lookup_block_device()), e.g.
IOReadBandwidthMax=/dev/sda1 18879
IOReadBandwidthMax=/dev/sda2 18878
where both partitions resolve to /dev/sda and when these values are
applied (they are associated with original paths, i.e. as if applied for
different device) in the order from io_device_limits.
The parsing code prepends, so they end up in reverse order wrt config
file. Switch the direction so that the order of application matches the
order of configuration -- i.e. semantics in all other unit file
directives.
Apply same change to all directives that use per-device lists. (The
question whether partitions should be resolved to base device is
independent.)
And apply the changes equally to DBus properties write handlers.
Fixes#34126
Verity= is an image build concept, not a first boot concept, whereas
a partition designator is always available, so let's do the size stuff
based on that.
When removing a cgroup in unit_prune_cgroup(), read IO metrics to cache
them similar to the existing treatment of the CPU and memory usage data.
Note that we do not do this for the IP metrics as the firewall objects
are only destroyed in unit_free() and thus stay alive long enough to
be read out directly by all interested parties.
Fixes#26988.
We generally do _not_ want the same sysexts to be loaded in both initrd and
exitrd phases. The environment is completely different and it's unlikely that
the same code can be useful in both places. Nevertheless, it can be useful in
_some_ cases, for example when the sysexts contains debugging tools.
I think we don't need to differentiate between initrds and exitrds through
SYSEXT_SCOPE, because the two types are made available in completely different
locations and loaded through a different mechanism, with very little chance of
an initrd being loaded as an exitrd without an explicit admin action (or the
other way around). So let's not complicate our code or definitions by an
explicit "exitrd" sysext designator, but just clarify that "initrd" also
encompasses exitrds in this context.
A sencence like "The system manager does, a, b, c, which is really d, and e.",
it is generally understood that the manager also does "e". This can be
quite confusing if the manager cannot do "e", in our case unmount the file
system on which it is sitting.
Similary, we cannot "fall back to x if it is missing", since "it" in that
sentence means "x".
The concept is fairly well established and present in our docs in various
places.
Say that the exitrd is also marked by the presence of /etc/initrd-release.
We need to make sure the presets from /usr/lib/systemd/user-preset
are applied as well. Currently only the ones from
/usr/lib/systemd/system-preset are applied.
The name of the parameter is misleading and it does not save us much
work because it is not used during regular unit property queries.
It is only used during unit_log_resources(), and the cgroup is already
dead by that point so it won't be read anyway.
When updating, I get a message like:
fatal: Not a valid object name a67221c3f0d0b81b9b5b3230a71d09044342f1a4^{commit}
The failure here is expected, it just means that an update is
necessary, so suppress output.
This uses the same logic as similar verb suggestion for command line
utilities. Try to be helpful when the user entered something invalid
instead of just showing the prompt again.