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

[Dariusz Gadomski]

Rodrigo, I have tried to make it work using --with-systemd flag passed
in d/rules, but every time I make a fix something else backfires. I
doubt it has ever been used before.

As a sidenote: we are lagging a lot behind upstream (they're at 2.4.4
already, we're at 1.3.4 and so is Debian). But we can't fix this for f
anymore.

I discussed this with ddstreet and we need to get Debian opinion on this. What could be tried is one of the following (for example):
1) debian/nfs-kernel-server.install should install from debian/tmp/lib/system/systemd-generators, and systemd/Makefile.am should pull genexec_PROGRAM Sout of INSTALL_SYSTEMD and also change /usr/lib/systemd/systemd-generators to /lib/...
or
2) use the build location to install from in nfs-kernel-server.install, and update systemd/Makefile.am to only build (not install) the generator, like:

 if INSTALL_SYSTEMD
+genexec_PROGRAMS = nfs-server-generator
 install-data-hook: $(unit_files)
 	mkdir -p $(DESTDIR)/$(unitdir)
 	cp $(unit_files) $(DESTDIR)/$(unitdir)
+else
+noinst_PROGRAMS = nfs-server-generator
 endif

I'm going to offer a MR to Debian and see what they say about it.

-- 
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 Committed
Status in nfs-utils source package in Bionic:
  New
Status in nfs-utils source package in Eoan:
  New
Status in nfs-utils source package in Focal:
  In Progress
Status in nfs-utils source package in Groovy:
  Fix Committed

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