[systemd-devel] [PATCH 4/4] mount: Add a new remote-fs* target to delay logins until home dirs are available

Colin Guthrie gmane at colin.guthr.ie
Tue Jul 10 10:07:05 PDT 2012


'Twas brillig, and Lennart Poettering at 10/07/12 17:16 did gyre and gimble:
> On Tue, 10.07.12 09:23, Colin Guthrie (gmane at colin.guthr.ie) 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 (colin at mageia.org) 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/



More information about the systemd-devel mailing list