Accurate time is a "good thing". There are a couple of services that help your server keep time correct. NTP (Network Time Protocol) runs as a client/server setup and syncs your server's time with other accurate time sources.
Timesyncd runs as a client service only (so it does not listen on any interface, and lowers your server's security risk profile). timesyncd is available on newer, systemd-based distros.
RimuHosting installs NTP on older (pre 2016) distros and timesyncd on newer distros (e.g. Ubuntu 16.04).
Run timedatectl to check if this is running.
If you have an existing install with systemd in place, you can disable or remove ntpd and then setup timesyncd instead as follows.
grep -qai '^NTP=' /etc/systemd/timesyncd.conf || echo "NTP='0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org ntp.ubuntu.com'" >> /etc/systemd/timesyncd.conf
service systemd-timesyncd start
timedatectl set-ntp true
If you have an older install (where RimuHosting have not already installed ntp) or prefer to install ntpd yourself use the following...
apt-get install ntpThat should configure reasonable servers for checking time from in /etc/ntp.conf but some good defaults may be...
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
driftfile /etc/ntp/ntp.drift
You should use more than one NTP server so that NTP can adjudicate time discrepancies. There is no point only having a single server listed. If that server's time drifts for some reason then it will cause your server's date to follow in lockstep, with mutuple servers to check against ntp uses some sanity checks to make sure the time stays more consistent.
Install it as a service. In CentOS do
chkconfig --add ntpd
chkconfig --level 35 ntpd on
/etc/init.d/ntpd start
... or in Debian/Ubuntu do ...
update-rc.d ntp defaults
update-rc.d ntp enable
/etc/init.d/ntp start
The fix to this permissions error to to run
touch /etc/ntp/ntp.drift /etc/ntp/ntp.drift.TEMP
chown ntp /etc/ntp /etc/ntp/ntp.drift /etc/ntp/ntp.drift.TEMP
You may find that even though ntp is running time may be drifting as if it is not being corrected. This can occur when ntp is misconfigured to not listen for network connections properly. By design the ntp server is configured to open port 123. And it also needs random high port numbers to connect to the world.
The main symptom is that ntp can discover upstream servers, but cant complete the connection to that. And so those servers get stuck in the INIT state. An example of that behaviour can be see in the below output.
root@test.com:~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ds001.hostingsh .INIT. 16 - - 1024 0 0.000 0.000 0.000
a.pool.ntp.uq.e .INIT. 16 - - 1024 0 0.000 0.000 0.000
ns1.unico.com.a .INIT. 16 - - 1024 0 0.000 0.000 0.000
There are several things to check:
* if you use a firewall make sure that allows outgoing and incoming connections for the ntp server
* in debian/ubuntu make sure /etc/default/ntp does not force localhost only eg remove "-I 127.0.0.1"
* make sure /etc/ntp.conf has a line like the following "restrict default kod nomodify notrap nopeer noquery". More restrictive values will prevent that from properly initiating connections
Then restart the ntp service. You should see 'ntpq -p' results quickly change from the INIT state, which means it will be now be actively tracking those time servers
Some other general help is avilable on {link}http://support.ntp.org/bin/view/Support/TroubleshootingNTP{link}. And a good NTP read: http://linux.oreillynet.com/pub/a/linux/2003/01/02/ntp.html
RimuHosting : Server hosting service. A Rimu Hosting Ltd business. RimuHosting services include:
© RimuHosting Ltd 2002-2024. Rimuhosting, Launchtime and the Rimuhosting logo are RimuHosting™ trademarks.
