Bug 742746

Summary: Could the nfs services be made to wait for named?
Product: [Fedora] Fedora Reporter: Göran Uddeborg <goeran>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 16CC: bfields, harald, jlayton, johannbg, kay, lpoetter, metherid, mschmidt, notting, plautrba, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: nfs-utils-1.2.5-1.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-25 03:24:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Göran Uddeborg 2011-10-02 11:30:14 UTC
Description of problem:
When booting, I get error messages about exportfs and rpc.nfsd services being unable to resolve various host names.  (In the case of rpc.nfsd, it is because I've added a "-H" flag to its options.)

I believe this is because the services are started before named has come up.  In the messages file, I see messages from named coming up one second later.

Is there a way to avoid this problem?  I'm still unfamiliar with systemd, but I guess the "systemd way" to fix this would be to have a systemd socket configuration for the named sockets, so the nfs processes would wait for it to come up.  But there obviously isn't any yet, and named still uses SysV init files, so I'm not sure it would be possible to make that work.

Version-Release number of selected component (if applicable):
systemd-35-1.fc16.x86_64
bind-9.8.1-2.fc16.x86_64
nfs-utils-1.2.4-8.fc16.x86_64

How reproducible:
Every time so far, though I guess it could work occasionally since it is a timing issue.

Steps to Reproduce:
1. Configure exports that are only known in DNS, not in /etc/hosts
2. Add a -H flag with a similar address in /etc/sysconfig/nfs
3. reboot

Actual results:
Error messages like

Sep 30 20:12:59 mimmi exportfs[1458]: exportfs: Failed to resolve pluto

Sep 30 20:12:59 mimmi rpc.nfsd[1506]: rpc.nfsd: unable to resolve mimmi.uddeborg:nfs to inet address: Name or service not known
Sep 30 20:12:59 mimmi rpc.nfsd[1506]: rpc.nfsd: unable to set any sockets for nfsd
Sep 30 20:12:59 mimmi systemd[1]: nfs-server.service: control process exited, code=exited status=1

Expected results:
No error messages.

Additional info:
I'm not sure how serious the exportfs messages are.  Later on exportfs seems to work normally.  The rpc.nfsd service though fails because of it.

There are a number of trivial workarounds.
- Adding the names to /etc/hosts.
- Using IP numbers in the configurations.
- Restarting nfs-server.service after bootup.

To me, though, it seems this ought to work without any workarounds.  So I would argue it is a bug, although of low severity.

Comment 1 Michal Schmidt 2011-10-03 08:02:41 UTC
(In reply to comment #0)
> I believe this is because the services are started before named has come up.

Does it work if you add named.service to the 'After=' line in /lib/systemd/system/nfs-server.service ?

> I guess the "systemd way" to fix this would be to have a systemd socket
> configuration for the named sockets, so the nfs processes would wait for it to
> come up.  But there obviously isn't any yet, and named still uses SysV init
> files, so I'm not sure it would be possible to make that work.

Socket activation is possible only with native units, not with SysV.

Reassigning to nfs-utils for consideration if an ordering dependency should be added.

Comment 2 Steve Dickson 2011-10-03 15:13:35 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > I believe this is because the services are started before named has come up.
> 
> Does it work if you add named.service to the 'After=' line in
> /lib/systemd/system/nfs-server.service ?
> 
> > I guess the "systemd way" to fix this would be to have a systemd socket
> > configuration for the named sockets, so the nfs processes would wait for it to
> > come up.  But there obviously isn't any yet, and named still uses SysV init
> > files, so I'm not sure it would be possible to make that work.
> 
> Socket activation is possible only with native units, not with SysV.
> 
> Reassigning to nfs-utils for consideration if an ordering dependency should be
> added.
I went ahead and added named.service to the 'After=' on the rawhide
build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3399166

Please let me know if it helps...

Comment 3 Göran Uddeborg 2011-10-05 20:29:44 UTC
The machine isn't quite enough of a "test only" machine that I dare move it to rawhide.

But I did the same thing manually.  I added "named.service" to the end of the "After=" line in the installed /lib/systemd/system/nfs-server.service and it seems to fix the problem just fine.  Both exportfs and rpc.nfsd came up nicely, just after named was ready.  (Well, I don't actually see when exportfs is run.  But I do see a message from rpc.nfsd about not being able to use any inet6 address immediately after the last named message.)

Comment 4 Steve Dickson 2011-10-06 01:46:17 UTC
(In reply to comment #3)
> The machine isn't quite enough of a "test only" machine that I dare move it to
> rawhide.
> 
> But I did the same thing manually.  I added "named.service" to the end of the
> "After=" line in the installed /lib/systemd/system/nfs-server.service and it
> seems to fix the problem just fine.  Both exportfs and rpc.nfsd came up nicely,
> just after named was ready.  (Well, I don't actually see when exportfs is run. 
> But I do see a message from rpc.nfsd about not being able to use any inet6
> address immediately after the last named message.)

Thank you for your effort! Unfortunately I'm take a few days off
so I will try to get this fix into F16 sometime next week..

Thank you again!

Comment 5 Fedora Update System 2011-10-13 17:25:25 UTC
nfs-utils-1.2.5-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-1.fc16

Comment 6 Fedora Update System 2011-10-15 14:33:24 UTC
Package nfs-utils-1.2.5-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 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.2.5-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14368
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2011-10-25 03:24:34 UTC
nfs-utils-1.2.5-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.