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?

1 Answer 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

  • Ok, I guess I didn't understand it as well as I thought. I'm removing my answer because of the inaccuracies.
    – Paul H.
    Commented Dec 26, 2016 at 16:00
  • 1
    Thank you. This answers my question. I must have overlooked the /run/systemd/generator/local-fs.target.requires directory. What makes this directory (/run/systemd/generator) a directory where we can put unit files? I have not found it in any man pages.
    – Gradient
    Commented Dec 26, 2016 at 16:57
  • Reading systemd.generator(7), it seems like it is the generator that makes this directory known to systemd.
    – Gradient
    Commented Dec 26, 2016 at 17:08
  • So basically, the generator sets them to autostart (or not, for instance in the case of init.d scripts that aren't linked in via chkconfig, it just created systemd unit files for them and doesn't set them to autostart).
    – rogerdpack
    Commented May 9, 2019 at 16:09
  • I would add that units generated with the SysV generator are enabled by default if they are symlinked from /etc/rcX.d with an appropriate runlevel. Commented Jun 13, 2023 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .