Changes to dependency graph during boot

[Conrad Hoffmann <ch@xxxxxxxxxxxxx>]

Hi,

TL;DR: I was wondering what happens if a unit executed early during the
boot process changes the current dependency graph by either enabling or
even starting another unit that was previously disabled. Is this defined
behaviour, and if so what are the rules?

Longer version:

I am looking at an issue that seems to be with cloud-init in combination
with Arch Linux. Arch Linux uses systemd, and cloud-init is executed
(via units) multiple times during boot (running different cloud-init
modules at each stage). The idea is that one of the early cloud-init
modules writes a network config and the next stages' systemd unit
depends on network.target, so that e.g. systemd-networkd would be
started in between, reading the generated config and setting up the
network accordingly.

However, the Arch Linux implementation in cloud-init uses the netctl [1]
tool, which works a bit differently: there is a dedicated unit file for
each connection (called profile), and netctl can be used to switch
between them (or have multiple enabled at the same time). This has the
effect that since you don't know the network configuration in advance,
you also don't know what profiles/units to enable for boot, since they
will only be generated on first boot by the cloud-init service. As such,
the cloud-init code does what would seem like a reasonable idea: in
addition to generating the units for each connection, it also runs
`systemctl enable` for them. However, this does not seem to working. My
observations are that this does work on _second_ boot, however not on
the first one. I even tested runnig `daemon-reload` after `enable`, but
to no avail.

There are multiple ways on how the code could be made to work. But the
question of what to expect when running systemctl commands during boot
seemed both general and important enough (also in the wider context of
cloud-init) that I figured I should get some professional input before
making any assumptions :)

So the questions would be: a service executed by systemd during boot ...

• *enables* a previously disabled unit, what happens/should happen?
• *starts* a previously disabled unit, what happens/should happen?

In both cases, the implication is that the unit to be enabled/started
causes non-trivial changes to the dependecy graph.

[1] https://wiki.archlinux.org/index.php/Netctl

Thanks a lot,
Conrad
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel