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? This would of course mean that we'd handle local mounts and remote mounts differentl in this regard, but I guess that is OK since local mounts fail quickly, and remote mounts don't. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
