Post by James H. MarkowitzI have been using NTP all along, but my understanding is that NTP
has some problems both with its design and in the implementations under
all different flavors of Unix-like system. Is this correct? Should I move
to chrony?
What cases are you concerned about? A couple of years ago ntpd had a few
security vulnerabilities clustered around the same time, but its record
overall hasn't been bad.
Myself, I can only think of one case I care about, the make case. Say
I run for awhile with no network and my clock gets ahead somehow. I
build a program, then I reboot and quickly edit a file and run make
again. If ntpd had stepped the clock backwards the change could be
ignored since the object file looks newer than the source file.
I've been running with -x and -g options. The -x option will prevent it
stepping the clock unless it's more than 600 s off. -g will let it
step but only one time on start up. Without the -g ntpd will panic
with a log message if the clock is off by more than 1000 s.
I'm debating using an ntp.conf tinker option to instead always slew
and nothing else. If the clock gets way off I'll notice and can
adjust manually. That would protect me from ntpd stepping the clock
backwards and confusing a build. But is that the only way of going
backwards? Could a reboot give me a system time in the past too,
without ntpd's intervention?
Now I'm not so concerned, since I only have laptops with properly
functioning real time clocks. Every time I check the offset with
ntpq it is very good. But it might be nice if there was a setting
that would allow ntpd to step the clock forward no matter how great
the offset but never let it step backward. So far I haven't found
such an option.