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