| Summary: | DOC: we should document in more detail how network.target is defined (or actually not defined), and what NetworkManager-wait-online.service does | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Lane <tgl> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | bfields, hhorak, jlayton, johannbg, lnykryn, metherid, msekleta, notting, plautrba, steved, systemd-maint, vpavlin |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-14 02:47:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
I believe this problem is fixed in the latest version of nfs-utils (1.2.5-5) Please yum update to verify. (In reply to comment #1) > Please yum update to verify. Would be glad to, but I don't see anything later than nfs-utils-1.2.5-4.fc16 in yum or bodhi? (In reply to comment #2) > (In reply to comment #1) > > Please yum update to verify. > > Would be glad to, but I don't see anything later than nfs-utils-1.2.5-4.fc16 in > yum or bodhi? My bad... nfs-utils-1.2.5-4 is the latest... Did updating nfs-utils help with this problem? NAK: it's still broken with nfs-utils-1.2.5-5.fc16.x86_64 Tom, Here is a scratch build of nfs-utils rpm that should fix this. http://koji.fedoraproject.org/koji/taskinfo?taskID=3934191 Would you mind giving it a try? tia... (In reply to comment #6) > Would you mind giving it a try? Installed it ... no change in behavior. systemd is still starting both named and nfs-server before the LAN connection is up, and of course both of them fail to initialize sanely: named can't contact any root servers, and exportfs can't resolve any client names. The long and the short of it is that "After=network.target" doesn't mean a damn thing. This isn't just a problem for nfs-utils, I'm afraid. (In reply to comment #7) > (In reply to comment #6) > > Would you mind giving it a try? > > Installed it ... no change in behavior. systemd is still starting both named > and nfs-server before the LAN connection is up, and of course both of them fail > to initialize sanely: named can't contact any root servers, and exportfs can't > resolve any client names. > > The long and the short of it is that "After=network.target" doesn't mean a damn > thing. This isn't just a problem for nfs-utils, I'm afraid. Just for giggles... please give this systemd script a try... http://people.redhat.com/steved/.tmp/nfs-server.service Its basically the F17 version which adds a couple more services to the After= lines. tia, (In reply to comment #8) > Just for giggles... please give this systemd script a try... No change. (In reply to comment #9) > (In reply to comment #8) > > Just for giggles... please give this systemd script a try... > > No change. Darn! Thanks for the quick turn around! nfs-utils-1.2.5-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-6.fc16 Package nfs-utils-1.2.5-6.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-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8065/nfs-utils-1.2.5-6.fc16 then log in and leave karma (feedback). nfs-utils-1.2.5-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/nfs-utils-1.2.5-8.fc16 nfs-utils-1.2.5-8.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. nfs-utils-1.2.5-8.fc16 does not fix this problem: the filesystems still aren't exported during reboot. As stated in comment #0, the problem is that "After = network.target" is useless, because it doesn't actually wait for the network to become available. What happens if you enable NetworkManager-wait-online.service? (In reply to comment #16) > What happens if you enable NetworkManager-wait-online.service? Huh, that seems to do it; at least, NFS service came up as desired in two out of two reboot tries, whereas the success rate was indistinguishable from zero before. And a look into /var/log/messages shows that both named and nfs service don't start until NetworkManager has done its thing. Perhaps this BZ can be reclassified as a request for better documentation of the need for this service setting. Essentially, the problem is the ill-defined network.target, which depending on your interpretation of the LSB spec, can mean any of: - can bind to a network socket of any sort - have working loopback device - have some non-loopback connection to somewhere - have a fully routable address that goes to the Internet At Large - and if you have multiple public addresses, does network.target mean any or all of them? It's why it's better to have network awareness in the services themselves. For the services that require a bigger hammer like this, it makes sense to enable NetworkManager-wait-online.service for usage scenarios such as this. Now that we have systemd presets that can be applied and layered, we can even create a 'server-preset' that's delivered in some package that enables it for certain server usage cases while leaving it disabled for other usage cases that may not need it. (That's the idea, anyway.) In theory we could delay dns resolution until the server actually needs to authenticate a request from a client. But that would make typos in /etc/exports a lot harder to debug. And we'd also get weird transient errors if a client became reachable before the dns server. (In reply to comment #17) > (In reply to comment #16) > Perhaps this BZ can be reclassified as a request for better documentation of > the need for this service setting. I have now turned this into a documentation issue. I will write something upstream in the wiki, since this comes up all the time. There's now better documentation upstream: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget I have linked this from the FAQ and from the systemd man pages. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: nfs almost always fails to export filesystems when started at boot. The reason is that it tries to run "exportfs -r" before DNS service is available, so of course it fails to resolve any client system names listed in /etc/exports. Version-Release number of selected component (if applicable): nfs-utils-1.2.5-3.fc16.x86_64 How reproducible: at least 9 times out of 10, for me Steps to Reproduce: 1. Create /etc/exports including some exports to specific client systems, eg / clientname 2. Reboot. 3. Note "exportfs: Failed to resolve clientname" bleats in /var/log/messages, as well as that exportfs -v doesn't show these exports as active. Additional info: The config file is okay, as shown by the fact that a manual "exportfs -a" fixes it after bootup. For me, it seems not to work with either local or remote DNS server. Not quite sure why the local case doesn't work, but for remote case it's perfectly clear from the log that NetworkManager hasn't brought the LAN up yet when nfs-server service is started. You would think that having "After = network.target" in the service file would fix this, but it doesn't, because the systemd folk do not think that that actually requires any network to be available. I don't know what they think such a specification *should* mean, but obviously usability doesn't enter into it. Comparable configuration has worked for me in pretty much every previous Fedora release, so this is a serious usability regression.