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

[Lennart Poettering]

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?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.