'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. > 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. Yeah it does mean there is less symmetry but I think that's OK. The use case and needs are different so there is probably no point in artificially trying to keep them the same anyway. However it does seem a little strange that remote-fs.target can be active before the network is ready (and thus remote-fs.target can be active before remote-fs-pre.target). That seems a little screwy but I can see the logic behind the suggestion. Ultimately it's up to you and less "special" units is arguably a good reason for this if the above general quirk in how things would be ordered is something you can live with! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
