On Tue, Jun 06 2017, Steve Dickson wrote: > Hello, > > On 05/29/2017 06:19 PM, NeilBrown wrote: >> >> Systemd does not, and will not, support "bg" correctly. >> It has other, better, ways to handle "background" mounting. > The only problem with this is bg mounts still work at least > up to 4.11 kernel...
I don't think this is correct. In the default configuration, "mount -t nfs -o bg ...." runs for longer than 90 seconds, so systemd kill it. A working "bg" mount would successfully mount the filesystem is the server came back after 5 minutes. If you use current systemd in the default configuration, it won't. bg mounts do work sometimes, but I don't think they are reliable, and there seems to be no interest in changing this. Maybe the text should say "Systemd does not, and will not, reliably support "bg" mounts...". > > It appears there is a problem with a 4.12 kernel. The mount no > longer errors out with ECONNREFUSED it just hangs in the > kernel trying forever... It sounds like a bug to me but > maybe that change was intentional.. Anna?? Trond??? Might be related to my patch [PATCH] SUNRPC: ensure correct error is reported by xs_tcp_setup_socket() sent 25th May. > > So I'm a bit hesitant to commit this since not accurate, yet. > > Finally, the whole idea of systemd randomly/silently > strip off mount options is crazy... IMHO... It isn't exactly systemd, it is systemd-fstab-generator. The options lists in /etc/fstab are not all equal. Some are relevant to /bin/mount, some to mount.nfs, some to the kernel. I think /bin/mount processes the option lists before passing it to mount.nfs. There is no intrinsic reason that systemd-fstab-generator shouldn't do the same thing. > > Just because a concept that has been around for years > does not fix well in the systemd world it gets > rip out??? IDK... but I think we can do better than that. I could suggest that automount is uniformly better than bg. Give how long automount has been around, and how easy it is to use with systemd, it might be time to start encouraging people to stop using the inferior technology. I could say that, but I'm not 100% sure. The difference between automount and bg is that with bg it is easy to see if the mount has succeeded yet - just look for an empty directory. With automount, you'll typically get a delay at that point. We could possibly wind down that delay... > > Note, the 'bg' is used by clients that do want their > booting to hang by servers that are down so if the > option is rip out, boots will start hang. This > will make it very difficult to debug since the bg > will still exist in fstab. Not exactly. Current default behaviour is that systemd will wait 90 seconds, then kill the mount program and fail the boot. If we strip out "bg", the same thing will happen. I'm OK with the patch not being applied just yet. I think we need to resolve this issue, but it isn't 100% clear to me what the best resolution would be. So I'm happy to see a conversation happening and opinions being shared. I'd be particularly pleased if you could double check how "bg" is currently handled on some systemd-enabled system that you use. Does the mount program get killed like I see? Does boot succeed if there is a bg mount from an unresponsive server? Thanks, NeilBrown > > Again, the whole concept of systemd messing with mounts options > is just not a good one... IMHO.. > > steved. > >> >> Explain this. >> >> See also https://github.com/systemd/systemd/issues/6046 >> >> Signed-off-by: NeilBrown <ne...@suse.com> >> --- >> utils/mount/nfs.man | 18 +++++++++++++++++- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> >> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man >> index cc6e992ed807..7e76492d454f 100644 >> --- a/utils/mount/nfs.man >> +++ b/utils/mount/nfs.man >> @@ -372,6 +372,21 @@ Alternatively these issues can be addressed >> using an automounter (refer to >> .BR automount (8) >> for details). >> +.IP >> +When >> +.B systemd >> +is used to mount the filesystems listed in >> +.IR /etc/fstab , >> +the >> +.B bg >> +option is not supported, and may be stripped from the option list. >> +Similar functionality can be achieved by providing the >> +.B x-system.automount >> +option. This will cause >> +.B systemd >> +to attempt to mount the filesystem when the mountpoint is first >> +accessed, rather than during system boot. The mount still happens in >> +the "background", though in a different way. >> .TP 1.5i >> .BR rdirplus " / " nordirplus >> Selects whether to use NFS v3 or v4 READDIRPLUS requests. >> @@ -1810,7 +1825,8 @@ such as security negotiation, server referrals, and >> named attributes. >> .BR rpc.idmapd (8), >> .BR rpc.gssd (8), >> .BR rpc.svcgssd (8), >> -.BR kerberos (1) >> +.BR kerberos (1), >> +.BR systemd.mount (5) . >> .sp >> RFC 768 for the UDP specification. >> .br >>
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
