Il 07/12/2011 08:30, Harlan Stenn ha scritto: >>> If anybody knows of any *good* reasons to set the clock before starting >>> > > ntpd, please speak up. >> > >> > Indeed! >> > It is very handy to set the clock directly on system startup >> > (eg. when the external clock is lacking proper battery). >> > I've still got a bunch of system using it. >> > >> > Oh, and of course its very handy for diagnostics. > I'm not saying one should not set the clock on system startup. > > I'm saying I'm not aware of good reasons to set the clock before > starting ntpd at system startup.
I still use ntpdate -q as a debugging tool. But I have another case, as well. I had a case at $PREVIOUS_EMPLOYER where we had to do exactly that, or more precisely: stop ntpd, run ntpdate, then start ntpd again. We had a few faulty servers that, for some reason, kept setting the clock one or two hours backwards, depending if we had DST or not[*]. Something was happening in the line that the system rebooted/started with proper time and timezone, then read the UTC time from the hardware clock as it was local time, and set it on the system. When ntpd started, it aborted since the machine appeared way off than the tolerated amount. Of course we could dig down into the hairy configuration files of these boxes in order to open a case to either the hardware vendor, or to the distribution vendor. But we were pretty understaffed at the time; plus, keeping that server offline for the few hours needed to debug it was not an option, and we ended up with that patchy workaround. That is why I'd happily keep ntpdate... Ciao -- bronto [*] I am not going to tell which brand the machines were, and which Linux distro they were running: I don't want to go into an endless, useless flame regarding bad hardware and bad distros. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
