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

[Lennart Poettering]

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?

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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.