> > > > The best solution to this mess was to deprecate ntpdate, once there was a > way to provide all of the intended *and assumed* functionality of ntpdate > by > some other way. > > The first set was removing the need to set the time with ntpdate before > starting ntpd. The solution to this problem is -g, and perhaps calling > ntp-wait (which actually implemented a missing feature that had been needed > before). >
I don't think '-g' option to ntpd is a practical solution - since it takes way too long to set the local time. Given this, people will continue to use ntpdate or sntp to set the time in a one-shot way before actually running ntpd. > There will be a script called "ntpdate" for those folks who want to keep > running a program by that name. > That will be great. It'll also be super if the ntpd man page can be fixed so it doesn't say ntpdate is to be retired and that 'ntpd -q' is an alternative to using ntpdate. This is spreading a lot of misinformation and causing waste of time. My company changed all the configs in our product to use 'ntpd -q', only to realize the hard way that it is way slower than 'ntpdate' and then we had to revert back. - Mohit _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
