On Tue, 10.07.12 09:23, Colin Guthrie ([email protected]) wrote: > > 'Twas brillig, and Lennart Poettering at 09/07/12 23:58 did gyre and gimble: > > On Mon, 02.07.12 09:15, Colin Guthrie ([email protected]) wrote: > > > >> Previously, systemd-user-sessions.service started after remote-fs.target. > >> If the user had any NFS mounts defined, this prevented logins until these > >> were processed. > >> > >> If the user was using NFS for their home directories, this configuration > >> makes sense, but equally, the user may have remote mounts defined that > >> are non-critical for logins and thus shouldn't delay login availability. > >> > >> Even using the "nofail" mount option does not help as > >> systemd-user-sessions.service will still wait for remote-fs.target which > >> although it does not require units, it does still have to run, thus it > >> will wait for remote-fs-pre.target which in turn will wait for the > >> network to be ready. All these things will delay the startup. > >> > >> Therefore, rather than start after remote-fs.target directly, instead > >> provide an more granular remote-fs-login.target that will only have > >> dependances of fstab entries not marked with nofail. > >> > >> Thus if an NFS mount is not critical for logins, it should be marked > >> with nofail mount option and it will not delay the login availability. > > > > Hmm, so I wonder if it wouldn't be better if we'd simply drop the > > Before=remote-fs.target for nofail mounts entirely. Is there really a > > need to sync of them if apparently nobody cares? > > Hmmm, yeah, provided they were still WantedBy=remote-fs.target then they > should all be pulled in accordingly and the mount attempted at boot, but > with out the Before= then the target can complete earlier and allow > logins.
Hmm, so it turns out we already don't created the ordering dep for nofail mounts: http://cgit.freedesktop.org/systemd/systemd/tree/src/fstab-generator/fstab-generator.c#n293 So, I am am bit puzzled now, shouldn't this be sufficient? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
