https://bugzilla.novell.com/show_bug.cgi?id=337075
User martin.burnicki@meinberg.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=337075#c22
--- Comment #22 from Martin Burnicki
the ntp.conf~ was only a temporary file which is created and deleted by the init script. i renamed this file ntp.conf.tmp.
I've seen that this when I had a look at the rc script. I'd appreciate if we could it working without having to ntp.conf file and found that it basically works. Finally it's mostly a timing problem. See below.
i didn't find information about dynamic keyword, yet. but i think there is an alternative!
I'm afraid we need the "dynamic" keyword anyway in ntp.4.2.4. It is used to indicate that a peer configuration can be done later, even if currently no interface can be determined for that peer address. Look for FLAG_DYNAMIC in ntp_peer.c. Please note this has become the default behaviour in the current ntp-dev, so in the next stable release this keyword will be obsolete, but the behaviour will be same as now with "dynamic". What I've done and observed so far is: - Modified the rc script such that it doesn't touch the ntp.conf file - Run ntpd with the standard ntp.conf file and "-U 60" - Removed the /etc/sysconfig/network/*ntp script - Stopped ntpd - Set system time 2 hours past - Reboot without network connection - After reboot "local clock" is shown by "ntpq -p" - Connected network cable - New interface detected by ntpd < 60 secs later - DNS resolving of peers ~5 mins later (see below) - Associations added after DNS success - Synchronizing to pool server The ugly things are: - It takes up to 60 seconds until the interface is detected - It takes even more until DNS resolving is retried and succeeds
ntpdc allows to rescan devices with ifreload. the init script now reload the interfaces when nm told it that a device changed. this _should_ work and fix your problem from comment #20. are you able to test this?
Yes. This is a very good good idea. I hope this also speeds up the DNS lookup. This ntpdc command should be put into the /etc/sysconfig/network/*ntp file, and nothing else, if possible. And there's one more problem: If it takes some time until the network connection comes up then ntpd synchronizes to the "local clock" association before, which obviously "eats up" the "-g" parameter. This means if the initial time offset exceeds 1000 seconds then ntpd stops itself. A workaround for this should be to remove the local clock from ntp.conf. The "local clock" time source is only a fallback which shall allow ntpd to serve it's time to other clients even if no upstream server is available. More tests to come.
the -U method isn't a real solution for the problem because nm should tell the init script immediately after a interface change to load the server and i'm willing to wait 60 seconds.
Right. I'd also appreciate if the ntpdc ifreload command would make this obsolete. However, the best solution would be if ntpd could receive network routing information through the routing socket. Don't you know one of your colleagues at Novell who's familiar with the Linux routing sockets and could help to port the implementation of those sockets in ntpd to Linux? 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.