https://bugzilla.novell.com/show_bug.cgi?id=722304 https://bugzilla.novell.com/show_bug.cgi?id=722304#c9 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |varkoly@suse.com --- Comment #9 from Marius Tomaschewski <mt@suse.com> 2011-10-19 08:45:27 UTC ---
From comment #2: See also fate#307610, where it were requested to enable it and to improve nm-online itself to wait only for wired (ethernet) interfaces with cable connected and skip any waiting on e.g. wireless interfaces.
I've tested it a bit and AFAIS that the second part of fate#307610 does not work and there is always a delay of 30sec, also when there is no cable connected to the ethernet card (no another configurations defined or ever used before). (In reply to comment #7)
well, it might break stuff like remotefs which are behind NM connection (wifi), since it might not be instantaneous to get connection.
remotefs over wifi is not a good idea :-) and not a good example. NM is a /usr [==remotefs] depending service itself, so it can't support /usr on a remotefs at all. When somebody needs an another remotefs (e.g. /home) with NM, he should use NM dispatcher.d scripts for anyway. [In ifup case there are also ifservices(5) to do such things.] But YES: timeout 0 definitely breaks all services that are behind the network-remotefs, even the connection can be established. On my notebook it needs something about 10sec to get dhcp leases, .... When timeout is set to 30, for example the ntp timesync works at boot time. With timeout 0 it never works. [in case of ntp the time sync happens as soon as the network is up, because ntp monitors the link itself. but another services don't do]. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.