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

This problem is addressed by commit [0] which requires [1] to compile.

I have created a test package with those changes and confirmed the issue is addressed.

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

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

debdiff for focal

debdiff for groovy

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.

Debian merge request of the fix: https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/2

This bug was fixed in the package nfs-utils - 1:1.3.4-2.5ubuntu4

---------------
nfs-utils (1:1.3.4-2.5ubuntu4) groovy; urgency=medium

  [ Rodrigo Barbieri ]
  * d/p/fix-start-ordering-1.patch,
    d/p/fix-start-ordering-2.patch,
    d/p/fix-start-ordering-3.patch,
    d/nfs-kernel-server.install:
    - Fix systemd service start ordering (LP: #1871214)

 -- Dariusz Gadomski <email address hidden> Thu, 28 May 2020 17:45:23 -0400

Hello Rodrigo, or anyone else affected,

Accepted nfs-utils into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nfs-utils/1:1.3.4-2.5ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

IMHO an SRU is not justified here. The code changes are substantial ("only moving code around" hardly makes it low risk as the risk of unexpected interactions is the same) and affected users in Bionic and Eoan especially are unlikely to have new affected deployments and existing deployments are likely already worked around. I don't see the benefit to SRU this to existing users, particularly in Bionic and Eoan. So I am declining to accept this SRU for Bionic and Eoan.

However, as Timo has already accepted this into Focal I'll let that proceed, and if other SRU team members want to accept this into Bionic and Eoan they can do so.

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

Performed validation according to test case, attached output, updated tags

I've just finished speaking to Rodrigo about Bionic and Eoan. We think that a different resolution for Bionic and Eoan might be more suitable, and Rodrigo will investigate this. In the meantime, I'll leave the current uploads for Bionic and Eoan in the queue in case we decide to use them after all, but until we decide, please hold them in the queue.

This bug was fixed in the package nfs-utils - 1:1.3.4-2.5ubuntu3.1

---------------
nfs-utils (1:1.3.4-2.5ubuntu3.1) focal; urgency=medium

  [ Rodrigo Barbieri ]
  * d/p/fix-start-ordering-1.patch,
    d/p/fix-start-ordering-2.patch,
    d/p/fix-start-ordering-3.patch,
    d/nfs-kernel-server.install:
    - Fix systemd service start ordering (LP: #1871214)

 -- Dariusz Gadomski <email address hidden> Fri, 29 May 2020 08:32:24 +0200

The verification of the Stable Release Update for nfs-utils has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

After speaking to Robie and the customer, we will not be pursuing the SRU further back to eoan and bionic at this moment. Changing those to "Won't Fix".