]> git.ipfire.org Git - thirdparty/systemd.git/commit
fstab-generator: handle NFS "bg" mounts correctly. (#6103)
authorNeilBrown <neil@brown.name>
Tue, 4 Jul 2017 07:47:40 +0000 (17:47 +1000)
committerLennart Poettering <lennart@poettering.net>
Tue, 4 Jul 2017 07:47:40 +0000 (09:47 +0200)
commit65e1dee7dcf1668c25c32f0238c935708dbffbcf
tree68fe0bf25615de37b83147d3b181b7178ed791ac
parent45d1ffd51d963604d9f4f501fad46c83c647af1c
fstab-generator: handle NFS "bg" mounts correctly. (#6103)

When "bg" is specified for NFS mounts, and if the server is
not accessible, two behaviors are possible depending on networking
details.
If a definitive error is received, such a EHOSTUNREACH or ECONNREFUSED,
mount.nfs will fork and continue in the background, while /bin/mount
will report success.
If no definitive error is reported but the connection times out
instead, then the mount.nfs timeout will normally be longer than the
systemd.mount timeout, so mount.nfs will be killed by systemd.

In the first case the mount has appeared to succeed even though
it hasn't.  This can be confusing.  Also the background mount.nfs
will never get cleaned up, even if the mount unit is stopped.

In the second case, mount.nfs is killed early and so the mount will
not complete when the server comes back.

Neither of these are ideal.

This patch modifies the options when an NFS bg mount is detected to
force an "fg" mount, but retain the default "retry" time of 10000
minutes that applies to "bg" mounts.
It also imposes "nofail" behaviour and sets the TimeoutSec for the
mount to "infinity" so the retry= time is allowed to complete.
This provides near-identical behaviour to an NFS bg mount started directly
by "mount -a".  The only difference is that systemd will not wait for
the first mount attempt, while "mount -a" will.

Fixes #6046
man/systemd.mount.xml
src/fstab-generator/fstab-generator.c