[Bug 1871214] Re: [SRU] nfsd doesn't start if exports depend on mount

[Rodrigo Barbieri]

Hello Robie,

While I investigated this issue, I found workarounds #1 and #2 as you
can see in the description section. I also found the upstream fix which
is the proper implementation of workaround #2 (workaround #2 per se
wouldn't be backportable, hence it needs a "generator" to be dynamic). I
understand that the fix is a bit complex for a bionic SRU, therefore an
alternative could be workaround #1.

I tested workaround #1 within the scope of the bug and also a few corner
cases that came to my mind, and I can test it more extensively to ensure
it is safe for a bionic SRU. What do you think about it? Do you think
workaround #1 could be SRU'ed into bionic?

Just to add a bit more context to it: in xenial exportfs always returns
0, regardless of any error or what happens, therefore nfsd is always run
and is never prevented from running by exportfs failing. This is why the
bug doesn't happen in xenial. The motivation that led to exportfs return
value changing was so it could be properly scripted (as far as I can
tell, it was quite a controversial change, reverted and added back, see
[1]). Given that for the SRU of workaround #1 we would be changing just
the systemd file to add a "-" to ExecStartPre, the previous (xenial)
behavior is maintained in the system boot case, but it could still
return != 0 when scripted. The impact is also minor and easier to revert
(it is a one-liner)

Also, one of the corner cases that I investigated is that, in the xenial
behavior, the export can be created by nfsd even though the path is not
available. At boot time, the export would be available a few seconds
later when the path is available. Anyone trying to mount the path in
that short time window will not succeed (or ever if the path fails to be
mounted). In xenial, you can end up in the same situation manually by
setting up an export that doesn't exist, not necessarily having to be
set up at boot time, as this workflow is not prevented at all.


[1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=history;f=utils/exportfs/exportfs.c;h=a04a78984a6e4eac4321ca9cafcf5a3bace0486c;hb=HEAD

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1871214

Title:
  [SRU] nfsd doesn't start if exports depend on mount

Status in nfs-utils package in Ubuntu:
  Fix Released
Status in nfs-utils source package in Bionic:
  In Progress
Status in nfs-utils source package in Eoan:
  In Progress
Status in nfs-utils source package in Focal:
  Fix Committed
Status in nfs-utils source package in Groovy:
  Fix Released

Bug description:
  Reproduced in Bionic and Focal, packages 1:1.3.4-2.1ubuntu5.2 and
  1:1.3.4-2.5ubuntu3 respectively.

  Steps to reproduce:

  1) Set up a ISCSI client to a 1GB+ volume, mount it in /data and set fstab to mount at boot
  2) Create a folder in /data like /data/dir1 and set up /etc/exports to export it
  3) Reboot
  4) Notice nfs-server does not start. Check journalctl and see it was because of "exportfs -r" returning -1 because /data/dir1 is not available.

  In Xenial (1:1.2.8-9ubuntu12.2), exportfs always returns 0, so this
  bug is not present there.

  This can be workaroundable in two ways:

  1) Editing nfs-server.service and adding "-" in
  "ExecStartPre=/usr/sbin/exportfs -r" to be
  "ExecStartPre=-/usr/sbin/exportfs -r". This will retain xenial
  behavior.

  2) Editing nfs-server.service and removing "Before=remote-fs-
  pre.target" and adding "RequiresMountsFor=/data". This will cause the
  systemd service load ordering to change, and nfs-server will wait for
  /data to be available.

  #2 is the upstream approach with commit [0] where this new comment
  identifies mount dependencies and automatically sets up
  RequiresMountFor.

  [0] http://git.linux-nfs.org/?p=steved/nfs-
  utils.git;a=commitdiff;h=4776bd0599420f9d073c9e2601ed438062dccd19

  =======================================================================

  [Impact]

  Users attempting to export folders from iSCSI or any remote mounted
  filesystem will experience their exports not being available at system
  start up, requiring workarounds or manual intervention.

  [Test case]

  1. Reproducing the bug:

  1a. Set up a ISCSI client to a 1GB+ volume
  1b. Format /dev/<device> using mkfs.xfs
  1c. Mount it in /data and set fstab as follows to mount at boot

  UUID="<uuid_from_blkid>" /data xfs defaults,auto,_netdev 0 0

  1d. Create a folder in /data like /data/dir1 and set permissions as
  follows

  chmod 777 /data/dir1
  chown nobody:nogroup /data/dir1

  1e. Set up /etc/exports as follows to export it

  data/dir1 *(rw,async,root_squash,subtree_check)

  1f. Reboot
  1g. Notice nfs-server does not start. Running "showmount -e" displays error.

  2. No cleanup necessary

  3. Install the updated package that contains the fix

  4. Confirming the fix:

  4a. Reboot
  4b. Notice nfs-server starts sucessfully, "showmount -e" displays the exports. 

  
  [Regression Potential]

  Regression potential is minimal. The dependency commit only moves code
  around and the actual fix only introduces an external systemd-
  generator without changing actual pre-existing code.

  I tested and confirmed that the fix introduced [0] also covers the fix
  removed [1], so there should not be any regression on this particular
  code change as well.

  [1] http://git.linux-nfs.org/?p=steved/nfs-
  utils.git;a=commitdiff;h=1e41488f428cd36b200b48b84d31446e38dfdc50

  
  [Other Info]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1871214/+subscriptions