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!!!

Community
  • 1
musbach
  • 139
  • 7
  • 4
    _Nothing worked._ <-- Can you elaborate? `ntpdate -b` should work just fine to solve this. –  Jul 08 '16 at 22:23
  • I added some examples – musbach Jul 08 '16 at 22:31
  • 1
    Is this by any chance a VPS, or containerised environment, of some kind? – MadHatter Jul 09 '16 at 11:51
  • 1
    Also, in the example above, could you do a `date` *after* running `ntpdate-debian` and *before* restarting `ntpd`? – MadHatter Jul 09 '16 at 13:08
  • Sorry, I don't know what a VPS is. I am running a normal Ubuntu. Which information should I provide? – musbach Jul 09 '16 at 13:11
  • 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 Jul 09 '16 at 13:45
  • 1
    It is a physical server next to me. – musbach Jul 09 '16 at 14:35
  • 1
    Consider making sure ntpd is stopped, then deleting the drift file before restarting ntpd. – user Jul 09 '16 at 14:52
  • 1
    @musbach OK, thanks, that's not it. What about my request for an extra `date` command (see about five comments back)? – MadHatter Jul 09 '16 at 15:02
  • 1
    Please see amendments at the end of the question. – musbach Jul 09 '16 at 16:02
  • 2
    Kill ntp, then run `hwclock -s`, then _do not start ntp again_. Wait a few minutes and check the `date`. – Michael Hampton Jul 09 '16 at 16:20
  • 1
    Michael Hampton you are my hero of today! Thanks it worked!!!!! I had to reboot and to correct the file system. Many thanks to you and all who helped me! – musbach Jul 09 '16 at 17:49

1 Answers1

1

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

sudo service ntp stop
sudo ntpdate-debian
sudo service ntp start
Sledge Hammer
  • 143
  • 9
  • Please seee above. It doesn't work. – musbach Jul 09 '16 at 09: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 09 '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 09 '16 at 11:56
  • I had to wait a second more but the drift is still there. – musbach Jul 09 '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 09 '16 at 13:55
  • I published the ntp.conf. I thing that the ntpdate-debian has already the offset: -353547850.182477 sec – musbach Jul 09 '16 at 14:33