[systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
neilb at suse.com
Tue Jun 6 21:49:24 UTC 2017
On Tue, Jun 06 2017, Steve Dickson wrote:
> 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
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
> 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.
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?
> Again, the whole concept of systemd messing with mounts options
> is just not a good one... IMHO..
>> Explain this.
>> See also https://github.com/systemd/systemd/issues/6046
>> Signed-off-by: NeilBrown <neilb at 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).
>> +.B systemd
>> +is used to mount the filesystems listed in
>> +.IR /etc/fstab ,
>> +.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) .
>> RFC 768 for the UDP specification.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the systemd-devel