On Mon, 15.06.15 13:24, Jan Synáček (jsyna...@redhat.com) wrote: > > I have the following setup on a freshly updated Fedora Rawhide machine > with systemd-220-9.fc23.x86_64. > > # cat /etc/fstab > [comments left out] > UUID=d5ac823b-d0bd-4f7f-bf4b-5cc82d585a92 / btrfs > subvol=root 0 0 > UUID=ec79f233-055c-40fa-98e5-e2d77314913a /boot ext4 > defaults 1 2 > UUID=d5ac823b-d0bd-4f7f-bf4b-5cc82d585a92 /home btrfs > subvol=home 0 0 > 192.168.122.1:/srv/nfs /mnt/nfs nfs defaults 0 0 > /var/tmp/test.iso /mnt/nfs/content iso9660 loop,ro 0 0 > > Notice the last two lines. There is an NFS mount mounted to /mnt/nfs and > an ISO filesystem mounted into /mnt/nfs/content, which makes it > dependent on the NFS mount.
Please add "_netdev" to the mount options of the ISO mount, to let systemd know that you need the network for that. Otherwise systemd assumes the ISO mount is in fact a local mount (which is hence ordered before local-fs.target which in turn is before basic.target), while correctly detecting that the nfs mount is a remote mount (which is henece ordered before remote-fs.target which in turn is usually assumed to be started much later than local-fs.target). Since however the local mount is ordered after the remote mounts you get a cyclic dep loop. > Isn't systemd trying to delete too many jobs while resolving the cycles? Well, systemd removes jobs effectively randomly, since for the cycle breaking logic all units are the same. Of course, you might consider some jobs more important than others, but systemd doesn't know which ones those would be. There have been prior requests for a better cycle breaking strategy but so far I am not aware of any proposal that could really work and substantially better things. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
