There seems to be no error per se. RequiresMountsFor=%s%s%s..%s%s%s is expanded to
RequiresMountsFor=/bin/zsh/bin/zsh/bin/zsh/bin/zsh/..., which takes a bit of time,
and then we iterate over this a few times, creating a hashmap with a hashmap
for each prefix of the path, each with one item pointing back to the original unit.
Takes about 0.8 s on my machine.
When using networkd we currently have no way of ensuring that static
neighbor entries are set when our link comes up. This change adds a new
section to the network definition that allows multiple static neighbors
to be set on a link.
Fixes the following error:
Failed to mount test /run: No such file or directory
By the time command "./test-udev check" calls function "fake_filesystems",
directory "test/run" must be present.
When there is a failure to setup the environment, the following happens:
1. Command "./test-udev check" exits with non-zero code.
2. Perl function "system" returns the code.
3. The code is evaluated as true by Perl.
Then we stop the test.
This provides us with an easy command line to test this script. Because
the test was so difficult to get running noone ever did, hence it broke
badly quickly. Let's fix that.
Previously, the test would use the existing static hostname. However,
this woud not work as expected in the static hostname was "localhost"
because the transient hostname will override the static one in that case
anyway, as the assumption hostnamed makes is that "localhost" is a
non-initialized hostname.
Hence when testing this, let's first set the static hostname to
something specific first (that is not "localhost").
Otherwise networkd isn't happy.
Let's also make addition of the "systemd-network" non-fatal. The user
exists on many machines anyway, hence it shouldn't fail if it already
exists.
Some controllers (like the CPU controller) have a performance cost that
is non-trivial on certain workloads. While this can be mitigated and
improved to an extent, there will for some controllers always be some
overheads associated with the benefits gained from the controller.
Inside Facebook, the fix applied has been to disable the CPU controller
forcibly with `cgroup_disable=cpu` on the kernel command line.
This presents a problem: to disable or reenable the controller, a reboot
is required, but this is quite cumbersome and slow to do for many
thousands of machines, especially machines where disabling/enabling a
stateful service on a machine is a matter of several minutes.
Currently systemd provides some configuration knobs for these in the
form of `[Default]CPUAccounting`, `[Default]MemoryAccounting`, and the
like. The limitation of these is that Default*Accounting is overrideable
by individual services, of which any one could decide to reenable a
controller within the hierarchy at any point just by using a controller
feature implicitly (eg. `CPUWeight`), even if the use of that CPU
feature could just be opportunistic. Since many services are provided by
the distribution, or by upstream teams at a particular organisation,
it's not a sustainable solution to simply try to find and remove
offending directives from these units.
This commit presents a more direct solution -- a DisableControllers=
directive that forcibly disallows a controller from being enabled within
a subtree.
Otherwise, some tests may disturb others, e.g.,
NetworkdNetWorkTests.test_routing_policy_rule_port_range and
NetworkdNetWorkTests.test_routing_policy_rule.
Not sure how I missed this, but we of course need to wait for the
"systemd-run" commands to finish before we can check the output files
this generated.
It tests importing and exporting, and a few other machinectl commands.
It currently does not test pulling (i.e. http downloads), but we might
want to add that later on.
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.
