When starting the network interface using DHCP and the cable is not plugged in, dhcpcd takes a long time to timeout by default: # time /etc/init.d/net.eth0 start * Bringing eth0 up via DHCP... [ !! ] real 2m0.130s This timeout can be adjusted via the dhcpcd_${IFACE} variable in /etc/conf.d/net. Here, I'm using dhcpcd_eth0="-t 10" # time /etc/init.d/net.eth0 start * Bringing eth0 up via DHCP... [ !! ] real 0m20.146s However, I think a better solution would be to check to see if the network cable is plugged in, and if not, report that information: # time /etc/init.d/net.eth0 start * Checking link status on eth0... * Link is down. Check cable connection. [ !! ] real 0m5.230s Or, if it is plugged in: # /etc/init.d/net.eth0 start * Checking link status on eth0... * Link is up [ ok ] * Bringing eth0 up via DHCP... [ ok ] * eth0 received address 192.168.1.100 I will attached a diff outlining the changes I made to /etc/init.d/net.eth0 to make this possible. This solution uses the 'mii-tool' command from the 'sys-apps/net-tools package.' I wasn't sure if the net-tools package was part of the 'system' packages, so I setup the script to check to see if /sbin/mii-tool is executable. If mii-tool isn't executable it continues as it did before. However, if mii-tool is executable the script uses it to check the link status. If the link is up, things continue as normal. If the link is down, it enters a loop and retries 5 times (one per second). If the link is still down at the end of this timeout, it reports the fact that the link is down and returns an error status. I think this solution is both more elegant than just setting a dhcpcd timeout and more information to the user. I hope you will consider incorporating this change.
Created attachment 36284 [details] Diff showing changes to net.eth0 required to solve problem
I'm pretty sure a lot of NICs don't correctly report whether they have a cable plugged in...
Yeah, bug #33272 is the mess that occurred last time we tried this. Too many buggy NICs out there for it to work... *** This bug has been marked as a duplicate of 33272 ***
*** Bug 65019 has been marked as a duplicate of this bug. ***