Bug 1115179 - nfs-server fails if hosts in exports can't be resolved
Summary: nfs-server fails if hosts in exports can't be resolved
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-01 19:32 UTC by Henrique Martins
Modified: 2016-11-15 06:05 UTC (History)
9 users (show)

Fixed In Version: nfs-utils-1.3.0-2.3.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-10 06:44:24 UTC


Attachments (Terms of Use)
nfs-utils.spec patch to fix bad dates in %changelog (6.94 KB, patch)
2014-08-03 14:20 UTC, Henrique Martins
no flags Details | Diff
nfs-utils.spec patch for bad dates in %changelog (6.94 KB, text/plain)
2014-08-03 14:31 UTC, Henrique Martins
no flags Details
nfs-utils.spec patch for bad dates in %changelog (6.28 KB, patch)
2014-08-03 14:33 UTC, Henrique Martins
no flags Details | Diff
exportfs patch (1.68 KB, patch)
2014-09-05 17:09 UTC, Henrique Martins
no flags Details | Diff
empty exportfs patch (806 bytes, patch)
2014-11-14 17:45 UTC, Henrique Martins
no flags Details | Diff

Description Henrique Martins 2014-07-01 19:32:43 UTC
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:

Comment 1 J. Bruce Fields 2014-07-01 20:51:20 UTC
Could you explain why you need this?

Comment 2 Henrique Martins 2014-07-01 21:12:17 UTC
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.

Comment 3 J. Bruce Fields 2014-07-01 21:24:25 UTC
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?

Comment 4 Henrique Martins 2014-07-01 21:29:44 UTC
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.

Comment 5 J. Bruce Fields 2014-07-01 21:36:58 UTC
What you'd do is mail a patch to linux-nfs@vger.kernel.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.

Comment 6 Henrique Martins 2014-08-03 14:13:13 UTC
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.

Comment 7 Henrique Martins 2014-08-03 14:19:31 UTC
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@vger.kernel.org

Comment 8 Henrique Martins 2014-08-03 14:20:29 UTC
Created attachment 923627 [details]
nfs-utils.spec patch to fix bad dates in %changelog

Comment 9 Henrique Martins 2014-08-03 14:31:32 UTC
Created attachment 923629 [details]
nfs-utils.spec patch for bad dates in %changelog

removes patches for client.c left in previous version

Comment 10 Henrique Martins 2014-08-03 14:33:33 UTC
Created attachment 923630 [details]
nfs-utils.spec patch for bad dates in %changelog

again (working on two machines, edited the wrong one...)

Comment 11 Steve Dickson 2014-09-04 16:19:34 UTC
(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@martins.cc>
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@redhat.com>

Will be posting a patch to  linux-nfs@vger.kernel.org WRT
Comment6 ?

Comment 12 Henrique Martins 2014-09-04 16:37:32 UTC
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.

Comment 13 Steve Dickson 2014-09-04 17:38:25 UTC
(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...

Comment 14 Henrique Martins 2014-09-04 19:16:07 UTC
I'll try to implement (mostly test) the latter then.
Not sure when I can get to it, may take a couple of weeks.

Comment 15 Henrique Martins 2014-09-05 17:09:48 UTC
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@vger.kernel.org

Comment 16 Steve Dickson 2014-10-31 13:36:43 UTC
(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@vger.kernel.org

I don't see this patch on linux-nfs@vger.kernel.org. Was it ever posted?

Comment 17 Henrique Martins 2014-10-31 14:19:55 UTC
http://www.spinics.net/lists/linux-nfs/msg46500.html

Comment 18 Steve Dickson 2014-10-31 18:05:59 UTC
(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@redhat.com) and
ccing the list (linux-nfs@vger.kernel.org)... 

I just want to try and figure out how I missed... I 
wonder what else I'm missing... :-( 

tia!

Comment 19 Henrique Martins 2014-10-31 18:36:09 UTC
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

Comment 20 Fedora Update System 2014-11-04 21:15:09 UTC
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

Comment 21 Fedora Update System 2014-11-04 21:16:32 UTC
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

Comment 22 Fedora Update System 2014-11-05 19:24:18 UTC
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).

Comment 23 Fedora Update System 2014-11-10 06:44:24 UTC
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.

Comment 24 Fedora Update System 2014-11-13 18:13:33 UTC
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.

Comment 25 Levi Harper 2014-11-14 13:46:49 UTC
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).

Comment 26 Henrique Martins 2014-11-14 14:38:40 UTC
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

Comment 27 Henrique Martins 2014-11-14 17:45:43 UTC
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.

Comment 28 Levi Harper 2014-11-14 19:11:25 UTC
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.

Comment 29 Henrique Martins 2014-11-14 19:21:30 UTC
> 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.

Comment 30 Marek Zdunek 2014-11-15 13:33:27 UTC
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/

Comment 31 Henrique Martins 2014-11-15 15:23:40 UTC
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,


Note You need to log in before you can comment on or make changes to this bug.