fstab-generator: complain if people use the "bg" mount option for NFS #6046
Labels
Comments
poettering
added
fstab-generator
RFE 🎁
|
Also see thread on the ML: https://lists.freedesktop.org/archives/systemd-devel/2017-May/038912.html |
neilbrown
pushed a commit
to neilbrown/systemd
that referenced
this issue
Jun 8, 2017
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 clean 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 identical behaviour to an NFS bg mount started directly by "mount -a". Fixes systemd#6046
neilbrown
pushed a commit
to neilbrown/systemd
that referenced
this issue
Jun 9, 2017
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 clean 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 identical behaviour to an NFS bg mount started directly by "mount -a". Fixes systemd#6046 Signed-off-by: NeilBrown <neilb@suse.com>
neilbrown
pushed a commit
to neilbrown/systemd
that referenced
this issue
Jun 9, 2017
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 clean 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 identical behaviour to an NFS bg mount started directly by "mount -a". Fixes systemd#6046 Signed-off-by: NeilBrown <neilb@suse.com>
neilbrown
pushed a commit
to neilbrown/systemd
that referenced
this issue
Jun 30, 2017
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 systemd#6046 Signed-off-by: NeilBrown <neilb@suse.com>
neilbrown
pushed a commit
to neilbrown/systemd
that referenced
this issue
Jul 4, 2017
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 systemd#6046 Signed-off-by: NeilBrown <neilb@suse.com>
neilbrown
pushed a commit
to neilbrown/systemd
that referenced
this issue
Jul 4, 2017
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 systemd#6046
Werkov
pushed a commit
to Werkov/systemd
that referenced
this issue
Oct 23, 2017
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 systemd#6046 (cherry picked from commit 65e1dee) [fbui: adjust context] [fbui: 'infinity' value for the timeout option is not supported by v228. Changed to use '0' instead which is equivalent and the documentation suggests to use that anyways] [fbui: this patch obsoletes ef377e8, which thereby was reverted] [fbui: fixes bnc#874665] [fbui: fixes fate#323464]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We really should refuse operation if "bg" is used for NFS mounts, as it is not compatible with systemd's semantics. I figure stripping "bg" from the mount options in fstab-generator while printing a warning and directing users to "x-systemd.automount" sounds like the best approach.
The text was updated successfully, but these errors were encountered: