2

My server is in the future 2027:

# sudo ntpdate ptbtime1.ptb.de
9 Jul 00:04:01 ntpdate[10000]: step time server 192.53.103.108 offset -353547847.989546 sec
# date
Di 21. Sep 23:48:18 CEST 2027
# hwclock
Sa 09 Jul 2016 02:03:56 CEST  -0.234935 Sekunden

The drift is huge with more than 10 years ahead. I cannot change the drift with "normal" resettings. I read already a couple of articles and I tried a lot of things like ntpdate –b,ntpd -gq or tinker panic 0. I change time zone and I tried to set the date/time manually. Nothing worked. How can I correct this? Please could somebody help me? I am running on Kubuntu 14.04 LTS (GNU/Linux 3.13.0-66-generic i686)

==================================================================

Could this cause a problem?

# sudo service ntp stop
 * Stopping NTP server ntpd                                                                             [ OK ]
# ntpq -p
ntpq: read: Connection refused

==================================================================

# sudo service ntp stop
 * Stopping NTP server ntpd                                                                                      [ OK ]
# sudo ntpd -gq
ntpd: time set -353547849.485594s
# sudo service ntp start
 * Starting NTP server ntpd                                                                                      [ OK ]
# date
Mi 22. Sep 11:39:09 CEST 2027

====================================================================

Please note How far is "too far off" for ntpd? Can it get there by a sudden jump to heavy load? Can this be overridden? "According to the manual page ntpd won't work if your clock is more then 1000 seconds off."

====================================================================

I tried to change it manually:

# date
Mi 22. Sep 11:32:09 CEST 2027
# sudo date --set="2016-07-09 11:50:59.990"
Sa 9. Jul 11:50:59 CEST 2016
# date
Mi 22. Sep 11:35:08 CEST 2027

==================================================================

I can enhance the drift with date --set "-1 year". But I cannot reduce it.

=========================================================================

It dosen't work:

# sudo service ntp stop
 * Stopping NTP server ntpd                                                            [ OK ]
# sudo ntpdate-debian
 9 Jul 14:56:52 ntpdate[3684]: step time server 131.188.3.220 offset -353547850.182477 sec
# sudo service ntp start
 * Starting NTP server ntpd                                                            [ OK ]
# date
Mi 22. Sep 14:41:25 CEST 2027

Update: I wasn't patient enough. I had to wait a second more but the huge drift is still there.

=====================================================

The /etc/ntp.conf

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
tinker panic 0

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Specify one or more NTP servers.

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
server ntp.ubuntu.com
server pool.ntp.org
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

# Use Ubuntu's ntp server as a fallback.
server ntp.ubuntu.com

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust

=====================================================

I tried also sntp

# sudo sntp -s ntp.ubuntu.com
22 Sep 12:53:56 sntp[17210]: Started sntp
2027-09-22 12:53:56.128427 (-0100) -353533451.192434 +/- 0.049652 secs
2027-09-22 12:53:56.155758 (-0100) -176766725.596156 +/- 0.024307 secs
2027-09-22 12:53:56.183422 (-0100) -265150088.380065 +/- 0.049652 secs
# date
Mi 22. Sep 12:54:01 CEST 2027

=====================================================

Here is the date directly after ntpdate-debian:

# date
Mi 22. Sep 12:54:40 CEST 2027
# sudo ntpdate-debian -s ntp.ubuntu.com && date
Sa 9. Jul 17:15:02 CEST 2016
# date
Mi 22. Sep 12:59:20 CEST 2027
# sudo ntpdate-debian -s ntp.ubuntu.com && date && date && date
Mi 22. Sep 13:00:21 CEST 2027
Mi 22. Sep 13:00:21 CEST 2027
Mi 22. Sep 13:00:21 CEST 2027
# sudo ntpdate-debian -s ntp.ubuntu.com && date && date && date
Sa 9. Jul 17:16:44 CEST 2016
Mi 22. Sep 13:00:55 CEST 2027
Mi 22. Sep 13:00:55 CEST 2027

=====================================================

Deleted drift files:

sudo service ntp stop
rm /etc/adjtime
rm /var/lib/ntp/ntp.drift
shutdown –h now

After reboot /var/lib/ntp/ntp.drift is empty. /etc/adjtime is

0.000000 1821611426 0.000000
1821611426
UTC

The date/time is stil the same. Where is the drift stored?

========================================================

Solution

by Michael Hampton:

I stopped ntp (checked with ps –aux | grep ntp) and used hwclock –s:

# sudo service ntp stop 
* Stopping NTP server ntpd                                                                                         [ OK ]
# sudo hwclock --set --date="7/9/16 18:37:30"
# hwclock
Sa 09 Jul 2016 18:37:34 CEST  -0.047338 Sekunden
# hwclock -s
# hwclock
Sa 09 Jul 2016 18:37:47 CEST  -0.984834 Sekunden
# hwclock
Sa 09 Jul 2016 18:38:01 CEST  -0.219219 Sekunden
# date
Mi 22. Sep 00:24:34 CEST 2027
# date
Mi 22. Sep 00:29:32 CEST 2027
# date
Mi 22. Sep 00:33:49 CEST 2027

I had to reboot and I had to correct the file system because it complaint that the last file system check was in the future.

Many thanks to all who helped me and a very special thank you to Michael!!!

  • 4
    Nothing worked. <-- Can you elaborate? ntpdate -b should work just fine to solve this. – yoonix Jul 8 '16 at 22:23
  • 1
    Is this by any chance a VPS, or containerised environment, of some kind? – MadHatter supports Monica Jul 9 '16 at 11:51
  • 1
    Also, in the example above, could you do a date after running ntpdate-debian and before restarting ntpd? – MadHatter supports Monica Jul 9 '16 at 13:08
  • 1
    Is it a physical server, or a virtualised server, or a containerised one? If either of the latter two, what technology is being used to virtualise/containerise it? If you can't answer any of those questions, you should probably talk to your provider - and you might want to ask them about the clock while you're at it! – MadHatter supports Monica Jul 9 '16 at 13:45
  • 2
    Kill ntp, then run hwclock -s, then do not start ntp again. Wait a few minutes and check the date. – Michael Hampton Jul 9 '16 at 16:20
1

Since you're running a Debian based distro try the following:

sudo service ntp stop
sudo ntpdate-debian
sudo service ntp start
  • Please seee above. It doesn't work. – musbach Jul 9 '16 at 9:50
  • @musbach - The error you got (22 Sep 11:30:21 ntpdate[3569]: the NTP socket is in use, exiting) means that for some reason the NTP service is still up and running. After you do sudo service ntp stop execute the following ps aux | grep ntp and after that kill the ntp process ID and then execute the ntpdate-debian command. – Sledge Hammer Jul 9 '16 at 11:13
  • Actually you can disregard what I said above about ps and kill and use sudo pkill ntp instead of sudo service ntp stop and then try again with sudo ntpdate-debian. – Sledge Hammer Jul 9 '16 at 11:56
  • I had to wait a second more but the drift is still there. – musbach Jul 9 '16 at 13:08
  • @musbach - From your latest edit it seems that ntpdate-debian works but things brake after you start the ntp service again so as a temporary solution you might want to keep it stopped until someone figures out what the problem is. You might also want to publish the content of your ntp config file (/etc/ntp.conf) – Sledge Hammer Jul 9 '16 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.