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

[Colin Guthrie]

'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.

> 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/