https://bugzilla.novell.com/show_bug.cgi?id=337075#c3
--- Comment #3 from Martin Burnicki
i'm not really understanding - xntp is starting to early because the init script checks if network is up. networkmanager tell this when he is started but not then the interfaces are up - this annoying! but after each interface up/down xntp is restartet so it stops and start like before only with network interface up.
As already mentioned, this is a fresh installation of 10.3 on a workstation, so networkmanager is not being used, in conformity with the proposal made by the installation routine. I agree that it's basically just annoying if ntpdate/ntpd are run unsuccessfully before the network interfaces are up. Normally this should just result in an error message, and when ntpdate/ntpd are run the next time after all interfaces are up they should succeed. Appearently startup of ntpd even does succeed in some cases. However, in some cases it does not. BTW, this problem has also been discussed on the opensuse-de mailing list on opensuse.org a few days ago. See: http://lists.opensuse.org/cgi-bin/search.cgi?query=startet+beim+Booten+nicht I don't know if you are speaking German. However, your name suggests you might be a native German ;-)
From what I've observed it seems that at least ntpd does not start successfully if there is an initial time offset which has to be compensated.
In this case the last start of ntpd occurs when either ntpdate or ntpd from an earlier start are still running. In this case NTP port 123 is still open, so ntpd cannot bind to it and terminates itself with the appropriate error message. Did you know recent versions of ntpd support dynamic interfaces? I.e. you could start ntpd before all network interfaces are up. Ntpd then does a cyclic rescan and binds to any new interfaces. Ntpdate, jowever, does not support dynamic scanning of interfaces so it will always fail the first time it is run (before interfaces are up), and may succeed the second time. I even could imagine this is the basic problem here. As already mentioned, the ntpdate/ntpd pair is run twice, the first time when initial network support (i.e. the loopback interface) is available, and the second time when full network support is available and the final runlevel is entered. I have not yet run more checks, but there are a few potential problems. Imagine there is some initial time offset when ntpd is run the first time. Since no network interfaces are up, ntpdate can not query its upstream servers and thus can not compensate the initial time offset. Immediately after ntpdate has been run ntpd is started the first time, also when the network is not yet fully up. Ntpd could stay in memory due to the new feature of dynamic interface scanning. However, it would have to wait until it could bind to the network interfaces in order to be able to reach its upstream servers and determine its own time offset. When this is the case then the large initial time offset would still be there since it could not have been compensated by ntpdate. If at this stage ntpd determines that the initial time offset exceeds the sanity limit (~1000 seconds) it would stop itself with an appropriate error message. This could be avoided if the -g option would be added to ntpd's command line, which lets ntpd accept an initial offset exceeding that sanity limit. So when the final runlevel is entered then the first instance of ntpd could still be running. If in this case ntpdate might not work, either, because ntpd has port 123 open. On the other hand, ntpdate could run successfully if it happens to run before ntpd has detected the newly appeared network interfaces, and bound to them. Anyway, now this the second instance of ntpd is started while the first instance may still be running. This would cause the error message mentioned above. A quick workaround might be to kill existing instances of ntpd before the rcntp script runs ntpd and then starts ntpd. However, the proper solution might be to avoid ntpdate, run ntpd only once, with the -g option to let it accept large initial time offsets. If ntpdate is really to be used it does not make sense to run it before the network interfaces are up. Additionally, the "iburst" keyword should be added to all server lines in ntp.conf anyway, in order to speed up synchronization. Martin -- 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.