Description of problem: nfs-server fails if hosts in exports can't be resolved Version-Release number of selected component (if applicable): nfs-utils-1.3.0-2.1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Add a host to /etc/exports that isn't resolvable 2. reboot or restart nfs Actual results: nfs-server fails to start Expected results: nfs-server should start and ignore bad entries in exports Additional info:
Could you explain why you need this?
Laptop with work machines in exports that aren't resolvable when I'm not in the office, and home machines in exports that aren't resolvable when I'm not home. I would have to have two files and switch to the proper one before starting nfs.
OK, that's interesting but kind of unusual. It wouldn't be a priority for me to fix personally but I think we'd probably accept reasonable patches. Writing a script that modified the configuration as you suggest, or maybe switching to IP addresses, might be workarounds for now?
I know how to work around it, just came here to suggest that this should be fixed. More interestingly is that this used to work, and now it doesn't. I'd look at a patch, which could be just as simple as ignoring that error, unless that has security implications I haven't thought off.
What you'd do is mail a patch to linux-nfs.org. I don't think the setup you're describing is something we'd normally encourage or support but if there's no obvious downsides to the patch then maybe it would be considered.
I finally had time to look at this, and I'm starting to believe that this started to happen with the switch to systemd. To fix it, all it takes is to prefix all three exec targets in nfs-server.service unit definition that invoke /usr/sbin/exportfs with a - to make systemd ignore the error exit code (probably ignored by the sysV init script in pre-systemd times, but I don't have one around anymore to check.) That error exit code is set to 1 (twice!) when running exportfs, and the code finds an unresolvable host name. In support/export/client.c, function client_lookup this sequence will do it once: ai = host_addrinfo(hname); if (!ai) { xlog(L_ERROR, "Failed to resolve %s", hname); goto out; } The L_ERROR causes xlog to set export_errno to 1, which is the value that exportfs returns. This could probably be avoided by replacing L_ERROR with L_WARNING, however a couple of lines above the call to xlog, there's a call to host_addrinfo (in support/export/hostname.c), which does: error = getaddrinfo(hostname, NULL, &hint, &ai); switch (error) { case 0: return ai; case EAI_SYSTEM: xlog(D_GENERAL, "%s: failed to resolve %s: (%d) %m", __func__, hostname, errno); break; default: xlog(D_GENERAL, "%s: failed to resolve %s: %s", __func__, hostname, gai_strerror(error)); break; } and the D_GENERAL, whichever case is used, also causes xlog to set export_errno to 1. Here I don't really understand what to replace D_GENERAL with as all other options don't seem appropriate, maybe use D_PARSE. I'll change the service definition on my own, not sure if changing in the rpm is an acceptable default behavior for fedora, will leave that up to you.
The nfs-utils.spec file that comes with the latest rpm generates a bunch of warnings when running rpmbuild, due to several bad dates in %changelog, I'll attach a patch here and also mail it to linux-nfs.org
Created attachment 923627 [details] nfs-utils.spec patch to fix bad dates in %changelog
Created attachment 923629 [details] nfs-utils.spec patch for bad dates in %changelog removes patches for client.c left in previous version
Created attachment 923630 [details] nfs-utils.spec patch for bad dates in %changelog again (working on two machines, edited the wrong one...)
(In reply to Henrique Martins from comment #10) > Created attachment 923630 [details] > nfs-utils.spec patch for bad dates in %changelog > > again (working on two machines, edited the wrong one...) These were committed... commit 23755331120d1bd7e0a87882160fe2feb49a604c Author: Henrique Martins <linux> Date: Wed Aug 13 09:49:46 2014 -0400 Clean up the changelog The spec file for nfs-utils-1.3.0-2.1.fc20 (nfs-utils.spec) has a bunch of bad date entries in %changelog which cause warnings when running rpmbuild. Signed-off-by: Steve Dickson <steved> Will be posting a patch to linux-nfs.org WRT Comment6 ?
Is that "Will you be posting", as in will I? And is that a patch to /usr/lib/systemd/system/nfs-server.service to disable checking for exportfs starting errors, or a patch to support/export/client.c support/export/hostname.c to change the xlog error codes? If the former I can do it easily, not sure if that is acceptable, if the latter, it will require some testing and an someone to tell me what the D_GENERAL/D_PARSE/WHATEVER codes are really used for.
(In reply to Henrique Martins from comment #12) > Is that "Will you be posting", as in will I? > > And is that a patch to > /usr/lib/systemd/system/nfs-server.service > to disable checking for exportfs starting errors, > or a patch to > support/export/client.c > support/export/hostname.c > to change the xlog error codes? > > If the former I can do it easily, not sure if that is acceptable, if the > latter, it will require some testing and an someone to tell me what the > D_GENERAL/D_PARSE/WHATEVER codes are really used for. I would say the latter... I don't think silently failing is the way to go... Changing the L_ERROR to an L_WARNING is probably the right way to go... Since it should not happen too often so it should not fill up people logs... If it does we can always change it... The D_XXX are generally for debugging The L_XXX are logging levels...
I'll try to implement (mostly test) the latter then. Not sure when I can get to it, may take a couple of weeks.
Created attachment 934872 [details] exportfs patch Adding patch to address comment #6, i.e. changing log levels for unresolvable exports to not generate errors, but adding an error if all exports are unresolvable. Also emailed to linux-nfs.org
(In reply to Henrique Martins from comment #15) > Created attachment 934872 [details] > exportfs patch > > Adding patch to address comment #6, i.e. changing log levels for > unresolvable exports to not generate errors, but adding an error if all > exports are unresolvable. > Also emailed to linux-nfs.org I don't see this patch on linux-nfs.org. Was it ever posted?
http://www.spinics.net/lists/linux-nfs/msg46500.html
(In reply to Henrique Martins from comment #17) > http://www.spinics.net/lists/linux-nfs/msg46500.html Wow, I can not find this patch at all in my inbox... Could you please resend it to me (steved) and ccing the list (linux-nfs.org)... I just want to try and figure out how I missed... I wonder what else I'm missing... :-( tia!
Well, re-sent to the list, and cc-ing you Let me know if you really want to be sent to you as requested in comment #18
nfs-utils-1.3.1-2.0.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/nfs-utils-1.3.1-2.0.fc21
nfs-utils-1.3.0-2.3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/nfs-utils-1.3.0-2.3.fc20
Package nfs-utils-1.3.1-2.0.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.3.1-2.0.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14286/nfs-utils-1.3.1-2.0.fc21 then log in and leave karma (feedback).
nfs-utils-1.3.1-2.0.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
nfs-utils-1.3.0-2.3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
The third portion of the exportfs patch (logging a L_ERROR message if there are no exports) prevents the nfs-idmap (rpc.idmapd) service from starting on our nfs client-only (no exports) systems. As I understand it (and recall from earlier experimentation), the idmap daemon is needed for both nfs clients and nfs servers. The failure is caused because the nfs-server service now fails to start due to a failed "ExecPreStart=/usr/sbin/exportfs -r" in the nfs-server unit file that the nfs-idmap unit file has a "After=" line referring to. If there's a better way to get the idmapd running on our clients than letting it start the server, I'm all for it. Likewise if I don't actually need to run idmapd on the clients (although I'm pretty sure I had to in the past).
That's an interesting twist, guess the patch should only put out L_ERROR if there are entries and all are unreachable. I'll look into making that change. Meanwhile change that entry (and others that refer to exportfs) to ExecPreStart=-/usr/sbin/exportfs -r
Created attachment 957688 [details] empty exportfs patch This patch should fix the empty exports file problem, as it only generates L_ERROR if the file only contains bad entries. It will be submitted to vger later. Meanwhile you could try installed this highly unofficial build http://www.martins.cc/linux/nfs-utils-1.3.0-2.4.fc20.x86_64.rpm to check if it works for you. At the moment I don't have an i686 system, real or VM, to build an i686 version.
I installed your build of nfs-utils-1.3.0-2.4 and it seemed to work fine for me (and the patch looks OK). I'm not sure I like the idea of erroring even if all the export entries fail due to name lookup errors, but then again I guess I just don't care for using hostnames in /etc/exports as they have to be resolved at a very different time than when the client connects... Regardless, my client systems work with the new build. Thanks for looking at it.
> I'm not sure I like the idea of erroring even if all > the export entries fail due to name lookup errors If you read through the comments on this bugzilla, the reason I filed it, and later on patched it, was that nfsd started erroring out when SOME of the entries in exports were unresolvable, let alone if ALL were unresolvable, and that broke one of my systems, a laptop with both home and work related entries in /etc/exports, where that setup worked for several years. No idea why that was changed, prior to my patch, but I didn't want to change it so I fixed it :-). Maybe you could debate that in the linux-nfs list.
after update to nfs-utils-1.3.0-2.3.fc20.x86_64 nfs failed to start /etc/exports doesnt exist on my machine, theres only /etc/exports.d ... lis 15 14:03:11 amd64 systemd[1]: Starting NFS Server... lis 15 14:03:11 amd64 exportfs[11150]: exportfs: No file systems exported! lis 15 14:03:11 amd64 systemd[1]: nfs-server.service: control process exited, code=exited status=1 lis 15 14:03:11 amd64 systemd[1]: Failed to start NFS Server. lis 15 14:03:11 amd64 systemd[1]: Dependency failed for NFSv4 ID-name mapping daemon. lis 15 14:03:11 amd64 systemd[1]: Dependency failed for NFS Remote Quota Server. lis 15 14:03:11 amd64 systemd[1]: Dependency failed for NFS Mount Daemon. lis 15 14:03:11 amd64 systemd[1]: Unit nfs-server.service entered failed state. journalctl -xn: http://fpaste.org/151042/
Give a try to the rpm referenced on comment #27 to see whethet it works for you, or if you don't trust it, just add a - at the beggining of all lines that reference exports in the systemd unit file, as in comment #26,