45bcfcb36c
This makes use of the option switch that was added in the previous commit. We used a pretty big hammer on a relatively small nail: we would do daemon-reload and (in principle) allow any configuration to be changed. But in fact we only made use of this in systemd-fstab-generator. systemd-fstab-generator filters out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on a big majority of systems it wouldn't do anything. Also, since systemd-fstab-generator first parses /proc/cmdline, and then initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the host would only matter if it the same mountpoint wasn't configured "earlier". So the config in the host could be used for new mountpoints, but it couldn't be used to amend configuration for existing mountpoints. And we wouldn't actually remount anything, so mountpoints that were already mounted wouldn't be affected, even if did change some config. In the new scheme, we will parse /sysroot/etc/fstab and explicitly start sysroot-usr.mount and other units that we just wrote. In most cases (as written above), this will actually result in no units being created or started. If the generator is invoked on a system with /sysroot/etc/fstab present, behaviour is not changed and we'll create units as before. This is needed so that if daemon-reload is later at some points, we don't "lose" those units. There's a minor bugfix here: we honour x-initrd.mount for swaps, but we wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be pulled in immediately.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.