|Summary:||Using PERSISTENT_DHCLIENT with no link present|
|Product:||[Fedora] Fedora||Reporter:||Paul B Schroeder <pschroeder>|
|Component:||initscripts||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brock Organ <borgan>|
|Fixed In Version:||8.52-1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-04-16 22:12:36 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Paul B Schroeder 2007-03-26 21:30:42 UTC
Description of problem: The machines we have come up significantly faster than the switch which they are connected to. Because of this, the network device never gets started. Setting PERSISTENT_DHCLIENT=yes solves part of the problem. The part that is causing a problem, however, is that ifup-ethX uses the check_link_down() function to determine if a link is present. If there is not link present, it exits and never bothers to start dhclient for the device. In this case, there is no link present yet as the switch is still booting. It would be nice if there were another option that could be added to ifcfg-ethX which would allow us to shut off the check_link_down() check. It would be nice to have in conjunction with PERSISTENT_DHCLIENT Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Configure eth device to use dhcp 2. Boot machine or restart the network without the network cable plugged in. 3. Actual results: The network interface and dhclient will not start. Expected results: Additional info: Created a quick, simple patch which essentially checks CHECK_LINK_DOWN to determine whether or not to execute the check_link_down function. Setting PERSISTENT_DHCLIENT=yes and CHECK_LINK_DOWN=no in a ifcfg-ethX and dhclient will always start.
Comment 1 Paul B Schroeder 2007-03-26 21:30:42 UTC
Created attachment 150965 [details] ifup-eth CHECK_LINK_DOWN patch
Comment 2 Bill Nottingham 2007-03-30 06:10:05 UTC
Why not just use LINKDELAY or NETWORKDELAY for your switch?
Comment 3 Paul B Schroeder 2007-03-30 06:25:25 UTC
(In reply to comment #2) > Why not just use LINKDELAY or NETWORKDELAY for your switch? We want devices to still come up normally if the switch is already up and the link is present. Wouldn't using those *always* create a delay at startup?
Comment 4 Bill Nottingham 2007-04-06 03:25:17 UTC
Hm. I'd wonder if in the case of PERSISTENT_DHCLIENT, the link status should be ignored *by default* - I'm not sure in what case you'd actually want to ever exit.
Comment 5 Paul B Schroeder 2007-04-16 19:37:37 UTC
(In reply to comment #4) > Hm. I'd wonder if in the case of PERSISTENT_DHCLIENT, the link status should be > ignored *by default* - I'm not sure in what case you'd actually want to ever exit. Didn't think about that prior.. But now that you mention it, yea, that seems to make the most sense.
Comment 6 Bill Nottingham 2007-04-16 22:12:36 UTC
Added in CVS, will be in 8.52-1.