nfsmount Doesn't Wait for net.wlan0 to Associate

[John R. Graham]

Actually, this happens with ntp-client service as well. These two services fail to complete properly, I believe, because, although the network interface has been started, wpa_supplicant hasn't yet associated to an access point when they try to start.

It doesn't seem to matter what I put in the rc_need in the appropriate /etc/conf.d/ file (or, at least, I haven't come up with the right answer). OpenRC appears to let the services try to start as soon as net.wlan0 has started. So, I end up without my NFS shares mounted and with my clock not most accurately set.

After I login, I can start those services (which show status "stopped") just fine and they always complete successfully. Of course, by then, the network is up and dhcpcd has gotten an IP address.

What am I doing wrong? As far as I know, this used to work but unfortunately I can't point to the change that made it stop working.

- John

[John R. Graham]

Polite bump.

- John

[Ant P.]

This might work, it makes dhcpcd wait in the foreground until it gets an IP:

Code: Select all

# /etc/conf.d/net
dhcpcd_wlan0="-w"

[John R. Graham]

Thanks. Alas, that didn't appear to do anything. I located the dhcpcd.conf option that did the same thing (waitip) and this did succeed in producing a very long timeout but didn't actually result in the nfsmount or ntp-client starting successfully. I'll report detailed logging shortly.

- John

[Odward]

I'd also be glad to know of a better solution, but I had the same problem with distcc failing to start because
the network wasn't ready. At the time I was using wicd, but I think the same thing could work for you.

My solution was to modify /etc/init.d/distccd

Code: Select all

start() {
         sleep 10
         ebegin "Starting distccd"

You can of course play with the necessary sleep time to suit your needs. I didn't actually test to see just how
small a sleep value I could get away with.

Also you may want to toy with the need / before / after type values to ensure that, for example, after
wpa_supplicant starts then ntp starts (with the sleep) then nfsmount can start (which won't need an additional
sleep since ntp already waited). Hopefully that makes sense, the goal being to prevent services requiring
the sleep for network to become ready from starting in a different order on a subsequent boot.

**Edit
I also realize this doesn't explain why / when it stopped working, and may not be an ideal solution :D
At the time I was personally using a static IP and had distcc configured to listen on that address, but I couldn't
figure out how else to make it wait for that address to become available for listening.

[John R. Graham]

Thanks for the thought. Yeah, that occurred to me, too. Since all I have to do to correct the situation for now is run

Code: Select all

sudo rc default

I'm committed discovering the correct solution and living with the only slightly annoying workaround until I do.

- John

[NeddySeagoon]

John R. Graham,

For your nfs shares, you can add bg to the mount options, that kicks the mount operation into the background and lets other things continue to start.
If you need the NFS shares for startup things, it may not be so good.

[krinn]

why not wait for your IP to get assign ?

Could add that after dhcp service, could add that as a service itself (says linkup) and make nfsmount depend on linkup

Code: Select all

ifconfig eth0 | grep 'inet' | cut -d: -f2 | awk '{ print $2 }'

[antonlacon]

For ntp-client, editing /etc/init.d/ntp-client to 'need net' (instead of 'after net') in the depend() section made it properly wait for wlan0 to authenticate. Filed a bug on it here: https://bugs.gentoo.org/show_bug.cgi?id=463974

[javeree]

The problem with any approach is that requirements can vary wildly.
What if you have a PC with multiple network interfaces, of which only some are up depending on varying conditions ? Which interface shoud nfsmount wait for ?
I may have a number of mounts I need to access through eth0 and a number that I need through eth1, and a third one through wlan0. However, when wan0 does not come up for any reason, I still want the mounts for eth0 and eth1 to succeed.

A solution may be to mount as late as possible, but then (as someone pointed out), other services may need one of these mounts.

You may even want nfsmount without any net interface at all (e.g. I share portage over nfs. For consistency of setup all PC's, including the one sharing portage mount it on /mnt/portage. The sharing PC doesn't need net to mount portage).

I have also strugled in the past and finally found there is no single solution that works every time. I have read on the theory of systemd and think this is one point where systemd may have a solution.
My solution was to put rc_after statements in /etc/conf.d/nfsmount, and retry failed mounts in local.start