Franck Bui
045c5faf5a
If an entry in fstab uses "x-systemd.automount" option and also asks for additionnal dependencies via x-systemd.requires or such, then the dependencies were applied to the automount unit. But this unlikely to do the right thing and is inconsistent with what's done for network mounts. Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the dependencies against the network requested by "_netdev" are (correctly) applied to the mount unit only and the automount unit remains ordered against local-fs.target. The same logic should be followed when extra deps are specified via the mount options as automount units should always be ordered against local-fs.target. Note: in general explicit deps specified via mount options should be used with care and should be used to specify dependencies on other mount units only as it can easily create ordering cycles otherwise like it's been seen in https://github.com/systemd/systemd-stable/issues/69. Mount units (as well as automount ones) are ordered before local-fs.target by default which is a low-level target that most other units depend on.
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 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.