Bugzilla – Bug 594224
sysconfig: reduce default wait time for unconfigured networks
Last modified: 2010-05-18 08:21:53 UTC
WAIT_FOR_INTERFACES=30 in /etc/sysconfig/network/config is somewhat long. Especially with lower-quality hosters that don't offer a serial console, I'd prefer for network to not wait forever.
I agree. Especially this is IMHO not needed at all on the LiveCDs.
There is no wait forever, but 30 secs. This is already a quite low timeout, because dhcp needs already 1..10 (random) secs sleeping at start as specified by RFCs. Further, the configuration of the interface is not optimal for some/your purposes, but for lowering it would break too many machines anybody, who is usually connected to the network. The network script does not wait for any interface when: - there is no interface config file (e.g. ifcfg-eth0) and there is _no_ interface config provided by sysconfig - the startmode in the interface config is 'hotplug' - the startmode in the interface config is 'ifplugd' (on cable connect) and no cable is connected. To disable the mandatory interface waiting, set either WAIT_FOR_INTERFACES=0 or MANDATORY_DEVICES=" " So for sysconfig, this request is INVALID. But in Live-CD case the config created there, it may be tunned to use e.g. 'ifplugd' instead of auto. Back to default Assignee.
30 seconds is an eternity ;-) The network script needs to deal with this fourth case: - there is no physical _interface_ by that name, such as when the NIC was replaced by a new one (like, swapping mainboard and thus the onboard LAN chip MAC). Because udev renamed this new NIC to eth1, rcnetwork will wait the entire 30 secs for an eth0 that will never appear.
sysconfig -> mt (yast2-network -> mzugec)
(In reply to comment #3) > 30 seconds is an eternity ;-) No, it isn't. This is a minimal timeout already required for systems that require network connection in further scripts (e.g. nfs/smbfs filesystems). Further, it waits in the background, because desktop is started earlier. > The network script needs to deal with this fourth case: > - there is no physical _interface_ by that name, such as when the NIC was > replaced by a new one (like, swapping mainboard and thus the onboard LAN chip > MAC). Because udev renamed this new NIC to eth1, rcnetwork will wait the entire > 30 secs for an eth0 that will never appear. This is not bug: WONTFIX or not optimal default setup in a corner case of a vanished hardware (wrong config in case of e.g. PCMCIA/USB/...). Note, that some NICs need time to initialize (e.g. bnx2 driver; a lot of Dell, ... hardware is using it) and lowering the timeouts, would break scripts that require network. So even in the above scenario of a replaced mainboard, 30 secs wait time is fine. The scripts will not wait when you set STARTMODE=hotplug or wait much shorter in case of STARTMODE=ifplugd (link/cable-connect detection). Please configure accordingly. Stephan, you seem to be the bug owner for LiveCD... In LiveCD case it IMO makes sense to use one of the above start modi instead of "auto" / "onboot". Except the LiveCDs are using NetworkManager anyway -- in this case it is IMO already covered by fate#307610. Should I reassign to you or close as WONTFIX/INVALID?
the live cds have NETWORKMANGER=yes - I suggest you go for WONTFIX, as Jan can clearly reconfigure this and you outlined your reasons.
WONTFIX, see previous comments.