NFS filesystems are not exported after booting when NetworkManager managed interfaces are needed for DNS resolution

[John Gilmore]

I have an 11.04 Natty system that was upgraded from earlier releases. It exports several filesystems via NFSv3 for use by other machines on the local network. When I boot the machine, those filesystems are not exported by default.

Immediately after logging in after a reboot, I can get a terminal and run "showmount -e", which shows no filesystems exported. If I then run "sudo exportfs -rv", it exports them without trouble.

The problem is that it doesn't do this by default. E.g. after a powerfail, it won't restart by providing the filesystems; I have to export them manually! What good is a server that doesn't serve?

In investigating other bugs relating to network service startup, I thought the problem might be that it tries to export to these hosts before DNS is available. So I installed bind9 and made it a secondary server for the relevant domains. Thus, it should be able to resolve domain names even before the network comes up. That didn't help.

[John Gilmore (gnu-gilmore)]

I have found a way to reconfigure the system to resolve the problem. However, there is still a bug in the default configuration of Ubuntu.

The problem DOES appear to be name resolution.

Even with bind9 installed, the local system is never configured to set /etc/resolv.conf to USE the local nameserver!

When I configured that manually, by editing /etc/resolv.conf, then rebooted, it properly exported the filesystems -- for
a single boot. But then NetworkManager overwrote /etc/resolv.conf with its own crazy idea of how to resolve domain
names, and on the second reboot, it failed to export the filesystems.

But this at least showed what the problem was. And enough talented sysadmins had already seen THIS problem that they came up with a big kludge script (apt-get install resolvconf) and patched all of the applications that love to clobber /etc/resolv.conf to call it. So after I installed the resolvconf package, and made sure that /etc/default/bind9 was set to "RESOLVCONF=yes" so that it would automatically inject localhost into resolvconf, everything started working.

This problem CLEARLY should be fixed in the default configuration. Forcing resolvconf and bind9 won't work, because the system can't know how to configure bind9 so it'll locally store a cache of the domain names that /etc/exports needs to resolve. I don't know how to fix this -- the complexities of upchuck are beyond me. I think you'll have to actually let upchuck know that, yes, /etc/exports MIGHT INDEED contain domain names and MIGHT INDEED have to look them up, so if domain service isn't yet working, then oops, DON'T RUN exportfs yet. Or, as an old programmer warrior often told me, "I can make your program run arbitrarily fast if you don't mind it producing the wrong answer." Upchuck has to produce the right answer -- THEN make things as fast as possible within that constraint.

[Clint Byrum (clint-fewbar)]

Hi John, man, sounds like you've been through the ringer on this one.

First off, if you have a truly static network connection that you always expect to be up on boot, I suggest using /etc/network/interfaces to define it. As of 11.10, the system will actually delay entering runlevel 2 (a.k.a. 'multiuser' mode) until all of these network interfaces are up. For earlier releases, one must modify /etc/init/rc-sysinit.conf to delay until the desired interface is up.

If you have a dynamic connection, things get trickier. I think there may be a solution here that has very little to do with upstart. When network-manager brings up interfaces, it looks in /etc/network/if-up.d and runs all those scripts for each interface. So the nfs-kernel-server package can add one of these which runs 'exportfs -a' each time an interface is brought up.

I really don't think its viable to involve bind9 or resolvconf in this situation. That is completely orthogonal to the issue of NFS not being able to export all of its exports because the network is not available.

Given all of that, I'm going to redirect this bug task to the nfs-utils package, as upstart really doesn't have anything to do with this particular issue.

Also I'm closing the upstream task. There's no deficiency in upstart itself that has been described here.