On my machine (Arch linux), systemd-generator generates some unit files in /run/systemd/generator/ and they seem to be started somehow on boot. What is starting them?
For example, boot.mount is generated by systemd. systemctl list-dependencies --all shows that it is linked to local-fs.target (which is not generated). How are they linked together? There is nothing in those two units that seems to trigger the start of boot.mount. Well, in boot.mount, there is Before=local-fs.target, but that does not start a service, does it?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Generated unit files are not automatically activated by systemd. There’s nothing special about them as far as systemd is concerned. Each individual generator has to explicitly create symbolic links that connect a generated unit to a target, so that activating the target activates the generated unit via a dependency in the normal way.
This takes advantage of the fact that not all connections between units are expressed inside the unit files. Wants and Requires dependencies can be expressed with symbolic link farms in *.wants/ and *.requires/ subdirectories. And those symbolic link farms encompass subdirectories of /run/systemd/ amongst other things.
In other words: Rather than write out a unit with WantedBy=local-fs.target and then have to explicitly invoke sytemctl enable to make the symbolic link (which is what enabling does), the generator short-circuits the process and makes the symbolic link itself. And it makes it in an ephemeral place, which systemctl enable normally would not, thereby preventing the symbolic link from continuing to exist after the next shutdown and confusing the next startup.
Specifically, you’ll find on your system that /run/systemd/generator/boot.mount is symbolically linked from /run/systemd/generator/local-fs.target.wants/boot.mount. systemd-fstab-generator created this symbolic link, and it makes boot.mount wanted by local-fs.target. The generator is run early in the bootstrap before the system gets around to activating local-fs.target, which means that when it does get around to activating local-fs.target the generated dependency is there to be followed.
Further reading
- https://unix.stackexchange.com/a/233581/5132
- Jonathan de Boyne Pollard (2016). “Missing system search paths from the
systemd.unitmanual page“. Errata for systemd doco. Frequently Given Answers.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0