timedatectl set-ntp no
apt install ntp -y
confirm:
ntpq -p
Optional change ntp.conf to Use pooling instead of servers:
vi /etc/ntp.conf
pool pool.ntp.org
minpoll 4
maxpoll 9
tos minclock 4 minsane 3
tos maxclock 8
clock peer sync sys
info events status statistics
logconfig =allall
statsdir /var/lib/ntp/stats
logfile /var/log/ntp
driftfile /var/lib/ntp/drift
pidfile /var/run/ntpd.pid
restrict default limited kod nomodify notrap nopeer noquery
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1
restrict source limited kod nomodify notrap noquery
service ntp restart
confirm:
ntpq -p
if you have a service like database,….. which needs to start after time synchronization, consider using command : /usr/sbin/ntp-wait -n 10 -s 2 -v
Note:
the line
/usr/sbin/ntp-wait -v
-may cause delay on services start, up to 10 minutes
-the command may fail on Correct Time or Failed time Sync
if you can’t wait, force time sync with:
ntpdate -u pool.ntp.org
Note: if you are setting a wrong time to test the ntpd, consider this:
ntpd
will refuse to set the clock if it’s too far out, and will just exit. I guess it’s to protect against some rogue NTP server giving it bogus time information. If a time server goes wrong and gives you info that is weeks/months/years out, it could cause havok for your server.
for testing purpose set the time to something nearly correct manually.
Note:
I’m in mood, so writing this note
having a correct time is important, but its dangerous for modern applications which produces/consumes data or services based on time. time attacks which can change the time on your server withing ntp or somehow you don’t know, will cause wrong data produce/consume/store.
if your are worry about this , consider writing a time travel detector script or program to avoid this attacks.