core: when Delegate=yes is set for a unit, run ExecStartPre= and friends in a subcgroup of the unit
Otherwise we might conflict with the "no-processes-in-inner-cgroup" rule
of cgroupsv2. Consider nspawn starting up and initializing its cgroup
hierarchy with "supervisor/" and "payload/" as subcgroup, with itself
moved into the former and the payload into the latter. Now, if an
ExecStartPre= is run right after it cannot be placed in the main cgroup,
because that is now in inner cgroup with populated children.
Hence, let's run these helpers in another sub-cgroup .control/ below it.
This is somewhat ugly since it weakens the clear separation of
ownership, but given that this is an explicit contract, and double opt-in should be acceptable.
Let's highlight the unit description string in the status updates, to
separate them a bit more the english sentence they are part of, and thus
make the different casing less surprising.
Harald Hoyer [Mon, 26 Nov 2018 10:41:29 +0000 (11:41 +0100)]
generator.c: systemd-fsck-root.service conflict with shutdown.target
Otherwise a "reboot" or "poweroff" in the initramfs will have to wait
until systemd-fsck-root.service has completed, which might never happen
if the root device never shows up.
Yu Watanabe [Mon, 26 Nov 2018 13:05:48 +0000 (22:05 +0900)]
test-network: add one more test for netdev dropin .conf files
For netdev, config files are loaded twice, and the first time,
only Match and NetDev setions are read. So, the test given by
the previous commit covers only the second loading.
This adds another test that also covers the first loading.
Yu Watanabe [Mon, 26 Nov 2018 02:57:48 +0000 (11:57 +0900)]
udevd: do not call udev_ctrl_enable_receiving() if the socket is passed from pid1
Before c4b69e990f962128cc6975e36e91e9ad838fa2c4, if the socket fd is
passed from pid1, `udev_ctrl_enable_receiving()` was not called.
Let's preserve the original logic.
Yu Watanabe [Sun, 25 Nov 2018 06:04:26 +0000 (15:04 +0900)]
udevd: do not set buffer size if the socket is passed from pid1
Before c4b69e990f962128cc6975e36e91e9ad838fa2c4, if the socket fd is
passed from pid1, `udev_monitor_set_receive_buffer_size()` (now it is
a wrapper of `sd_device_monitor_set_receive_buffer_size()`) was not
called. Let's preserve the original logic.
Yu Watanabe [Sun, 25 Nov 2018 05:52:24 +0000 (14:52 +0900)]
sd-device: do not call device_monitor_enable_receiving() for passed fd from pid1
Before c4b69e990f962128cc6975e36e91e9ad838fa2c4, if the socket fd is
passed from pid1, `udev_monitor_enable_receiving()` (now it is a wrapper
of `device_monitor_enable_receiving`) was not called.
Let's preserve the original logic.
units: order systemd-rfkill.socket after /var/lib/systemd/rfkill (#10904)
Otherwise we might install the socket unit early, but the service
backing it late, and then end up in strange loops when we enter rescue
mode, because we saw an event on /dev/rfkill but really can't dispatch
it nor flush it.
Unfortunately, f5f9a580dd4a3cf487b didn't help much and now
the next subtest gets stuck from time to time. Let's skip
test-execute altogether so as not to bother anybody with
spurious failures.
https://github.com/systemd/systemd/issues/10696 is still open.
Everybody is welcome to share ideas :-)
Thomas Haller [Fri, 23 Nov 2018 12:42:13 +0000 (13:42 +0100)]
dhcp6-client: handle IAID with value zero
config_parse_iaid(), dhcp_identifier_set_iaid() and sd_dhcp6_client_set_iaid() all
allow for the IAID to be zero. Also, RFC 3315 makes no mention that zero
would be invalid.
However, client_ensure_iaid() would take an IAID of zero as a sign that
the values was unset. Fix that by keeping track whether IAID is
initialized.
cgroup: when we unload a unit, also update all its parent's members mask
This way we can corectly ensure that when a unit that requires some
controller goes away, we propagate the removal of it all the way up, so
that the controller is turned off in all the parents too.
cgroup: drastically simplify caching of cgroups members mask
Previously we tried to be smart: when a new unit appeared and it only
added controllers to the cgroup mask we'd update the cached members mask
in all parents by ORing in the controller flags in their cached values.
Unfortunately this was quite broken, as we missed some conditions when
this cache had to be reset (for example, when a unit got unloaded),
moreover the optimization doesn't work when a controller is removed
anyway (as in that case there's no other way for the parent to iterate
though all children if any other, remaining child unit still needs it).
Hence, let's simplify the logic substantially: instead of updating the
cache on the right events (which we didn't get right), let's simply
invalidate the cache, and generate it lazily when we encounter it later.
This should actually result in better behaviour as we don't have to
calculate the new members mask for a whole subtree whever we have the
suspicion something changed, but can delay it to the point where we
actually need the members mask.
This allows us to simplify things quite a bit, which is good, since
validating this cache for correctness is hard enough.
cgroup: extend reasons when we realize the enable mask
After creating a cgroup we need to initialize its
"cgroup.subtree_control" file with the controllers its children want to
use. Currently we do so whenever the mkdir() on the cgroup succeeded,
i.e. when we know the cgroup is "fresh". Let's update the condition
slightly that we also do so when internally we assume a cgroup doesn't
exist yet, even if it already does (maybe left-over from a previous
run).
This shouldn't change anything IRL but make things a bit more robust.
cgroup: in unit_invalidate_cgroup() actually modify invalidation mask
Previously this would manipulate the realization mask for invalidating
the realization. This is a bit ugly though as the realization mask's
primary purpose to is to reflect in which hierarchies a cgroup currently
exists, and it's probably a good idea to keep that in sync with
realities.
We nowadays have the an explicit fields for invalidating cgroup
controller information, the "cgroup_invalidated_mask", let's use this
one instead.
The effect is pretty much the same, as the main consumer of these masks
(unit_has_mask_realize()) checks both anyway.