'Twas brillig, and Lennart Poettering at 10/07/12 17:16 did gyre and gimble: > 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?
Hmmm, very good question. I perhaps missed this when testing the general approach after you moved over to generators... :s If so, I apologise profusely (my defence being it was very much needed under systemd v44 :D) I'll do some more poking and see where I get. Sadly I'm having a few NFS issues right now due to kernel woes but hopefully that'll be fixed soon ish by our kernel guy (I'm too lazy to rebuild my kernel!) 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
