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 STS Sponsors, which is subscribed to the bug report. 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 -- Mailing list: https://launchpad.net/~sts-sponsors Post to : [email protected] Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
