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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
