On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote: > So in a situtation like that I never wait to ntpd to sync the time slowly. > I use ntpdate, but it can be used only if ntpd or other sync programs > doesn't use UDP123 port. So I stop ntpd and make an ntpdate <IP to > ntpserver> and the clock is stepped right after the syncronization.
ntpdate can set the clock BACKWARD as well as forward. Setting the clock backward can break all kinds of shit. Jumping the clock forward by a large amount can also break things, but it's not as bad as going backward. If you find that your mission-critical server has lost its clock sync for some reason, you're better off rebooting it. Assuming, of course, you have already fixed whatever caused ntpd to stop working in the first place. Because obviously you were running ntpd on it. Right? Right. Rebooting lets ntpd's -g option peform an ntpdate-like clock jump once again, and this will ideally happen BEFORE anything else that depends on the clock is started. So, if all is arranged correctly, by the time your time-sensitive services come back up, the clock will already be approximately correct, and it will be monotonically increasing as it finishes converging toward precision.
