I think the network init script as present in sys-apps/openrc-0.6.0 is prone to race conditions. It never seems to wait for the link to actually come up, after adding the addresses and setting it up... In my ifup_eth1 I had: ip link set up dev eth1; /usr/local/bin/ip-wait-for-link.sh eth1; ip -6 route add default via ... dev eth1; With that script being: while ip address show dev "$1" | grep -n NO-CARRIER > /dev/null ; do sleep 1 done (needed to be in a script, because the ;s in there confused openrc) So after adding the addresses, and after setting the link up, network should wait for it to actually finish, before adding any routes. Otherwise ip might complain about the device not existing. (I do not remember the actual error message that occured to me, but could probably reproduce it if really need be.) The timespan should be about 1-2s at max, so not really anything to worry about. Reproducible: Always
I don't understand why you are using ifup_eth1 to bring up the link? If you are trying to configure static addresses, you can use something like the following in /etc/conf.d/network: ip_eth1="[address/mask]" defaultiproute6="via [address] dev eth1" That will assign an address/mask to the interface, bring up the interface and set the default route.
(In reply to comment #1) > I don't understand why you are using ifup_eth1 to bring up the link? At the time I wrote this ip_eth1 simply did not work for my usecase, so I wrote my own ifup_eth1. I thereby noticed that I needed to wait for the link to come up before adding a route. I then checked the openrc default scripts, and noticed that there seems to be no code present which waits for the link to come up before proceeding. Thus I reported this bug about a possible race condition.
What is your use case in detail please? It would also help if you attach your /etc/conf.d/network so we can see what you are attempting to configure. I am using it this way to configure a static address and default route: ip_eth0="192.168.15.2/24" defaultiproute="via 192.168.15.1" It works perfectly for me. Thanks, William
You only see this with IPv6 addresses. There is a possible race condition as it stands right now.
I have a similar problem. After migrating to baselayout-2, boot process is accelerate quite a bit. This results in net depending services to be brought up before the link on the net device has been established. In my case, net.eth1 and net.wlan0 are started to obtain an IP address via dhcp. Since I use net.wlan0 to access my network at home and net.eth1 at work, I set rc_depend_strict="NO" because only one device will obtain an IP address. This results in both devices being brought up in background and thus net service marked being up. Now, net depending services are started. In my case, this is ntp-client which needs to resolve the name of the time server I configured. But association with my wifi ap and then obtaining an ip address has not been successful at this point and bringing up ntp-client fails. I managed to circumvent this problem at the moment by adding a 'before ntp-client' to the init script of one of my own service which takes some seconds to start up but I don't think that this can be referred to as proper solution. This is the output when net.{eth1,wlan0} is being started: * Bringing up interface {eth1,wlan0} * Starting wpa_supplicant on {eth1,wlan0} ... [ ok ] * Starting wpa_cli on {eth1,wlan0} ... [ ok ] * Backgrounding ... ... * WARNING: net.{eth1,wlan0} has started, but is inactive In baselayout-1, both devices were brought up in background as well, but net depending services were marked to be started after either of both were up. This behavior can be achieved by setting rc_depend_strict="YES" but, since one network device will never come up, all net depending services will remain unstarted. If you don't consider this a bug but a misconfiguration, please be so kind to point me to the documentation as I was not able to find anything about changing this behavior. Thanks for your great work, Roy and all others. Dustin
*** Bug 316687 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > *** Bug 316687 has been marked as a duplicate of this bug. *** > I have problems with netmount trying to mount an nfsv4 before eth0 is running. adding for int in $(interfaces); do while ip address show dev $int | grep -n NO-CARRIER > /dev/null ; do sleep 1 done done to the end of start() (just before return 0) helped me, no I do not know if/how you can do the same with ifconfig and/or if this is a portable solution...
Maybe I just misunderstood the keyword, but I think this is newnet related, not oldnet.
(In reply to comment #8) > Maybe I just misunderstood the keyword, but I think this is newnet related, not > oldnet. You are correct, this bug is about a race condition that has happened in the past with ipv6 addresses and newnet. Is this still happening for you?
(In reply to comment #9) > You are correct, this bug is about a race condition that has happened in the > past with ipv6 addresses and newnet. > > Is this still happening for you? There seems to be code in /etc/init.d/network which tries to wait for any interfaces which are not up. (Look at tentative() and how it is used.) It waits for all interfaces (not just the ones configured) and is a bit vague while parsing the output of /sbin/ip, but it seems to work as I haven't seen any race condition in a while.
(In reply to comment #10) > There seems to be code in /etc/init.d/network which tries to wait for any > interfaces which are not up. (Look at tentative() and how it is used.) > It waits for all interfaces (not just the ones configured) and is a bit vague > while parsing the output of /sbin/ip, but it seems to work as I haven't seen > any race condition in a while. Based on your response, I am marking this as resolved/fixed. Please re-open if the issue comes back. Thanks, William
