[Bug 722304] New: set NM_ONLINE_TIMEOUT=0 by defaulit
https://bugzilla.novell.com/show_bug.cgi?id=722304 https://bugzilla.novell.com/show_bug.cgi?id=722304#c0 Summary: set NM_ONLINE_TIMEOUT=0 by defaulit Classification: openSUSE Product: openSUSE 12.1 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: mt@suse.com ReportedBy: lnussel@suse.com QAContact: qa@suse.de CC: aj@suse.com, bili@suse.com Found By: --- Blocker: --- sysv boot waits for NM_ONLINE_TIMEOUT which is 30 seconds by default. Such a timeout is only needed for legacy services that can't deal with dynamic networking. Since such services don't make sense with NM having the timeout by default doesn't make sense either. Therefore NM_ONLINE_TIMEOUT should be set to zero by default. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c1
--- Comment #1 from Li Bin
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c2
--- Comment #2 from Marius Tomaschewski
I thought it's okay to set it to zero.
I'm going to change it for 12.1 back to 0 (only the default setting!!) when nobody stops me soon and commit/submit it tomorrow then. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c3
--- Comment #3 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c4
--- Comment #4 from Ludwig Nussel
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c5
--- Comment #5 from Marius Tomaschewski
I'm not sure it's necessary to change on update. I'd just leave the default empty for new installs and assume 0 in that case.
I were thinking about this, but it would introduce a difference between updated and fresh systems for people that were using old default before / never adjusted this setting... also not good. And there were already a hook migrating the setting from 0 to 30 (from old to new default) because of fate#307610. Now, I've changed it to migrate from old to new defaults without to check any particular value. But maybe you're right and it is better to remove the hook completely. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c6
Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c7
Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c8
--- Comment #8 from Ludwig Nussel
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c9
Marius Tomaschewski
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.
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c10
--- Comment #10 from Marius Tomaschewski
if anything depends on a 30 seconds timeout by default it's just plain broken. NM may never come online. If anyone encounters such a case please let me know. There needs to be another way to fix this, like e.g. hooking into ifup.d.
Yes, either if-up.d or ifservices(5) in case of ifup, dispatcher.d scripts in case of NM. The problem is, we _are_ starting init services at boot time by default and the timeout is the only thing that "protects them" at least in the case the connection works. With timeout=0 they'll always fail. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c11
--- Comment #11 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c12
Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c13
--- Comment #13 from Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c14
--- Comment #14 from Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c
Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c15
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c16
--- Comment #16 from Marius Tomaschewski
But I wouldn't put too much effort into the update case - NM_ONLINE_TIMEOUT should work as it's documented or support for it should go away (leaving 0 for everyone).
I interpret this as a ACK for patch (removed old migration hook) from comment 14 changing the default to 0 -- going to apply and submit it to factory today. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c17
Marius Tomaschewski
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c18
--- Comment #18 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c19
Raymond Wooninck
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c20
--- Comment #20 from Ludwig Nussel
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c21
--- Comment #21 from Raymond Wooninck
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c22
Ludwig Nussel
https://bugzilla.novell.com/show_bug.cgi?id=722304
https://bugzilla.novell.com/show_bug.cgi?id=722304#c23
Frederic Crozat
participants (1)
-
bugzilla_noreply@novell.com