I have a Debain console-only system.

I just realized it's not updating it's clock:

$ date
Mon 10 Aug 20:33:23 BST 2020

$ ntpdate
10 Aug 20:27:45 ntpdate[8029]: no servers can be used, exiting

$ ntpdate-debian
10 Aug 20:28:20 ntpdate[8038]: the NTP socket is in use, exiting

$ sudo ntpdate
10 Aug 20:33:53 ntpdate[8371]: no servers can be used, exiting

$ sudo ntpdate-debian
10 Aug 20:28:20 ntpdate[8038]: the NTP socket is in use, exiting


  • ntpdate can't work due to bad configuration (please see my config later)
  • ntpdate-debin can't work due to socket-in-use (ntp service is running)

After I stop "ntp service":

$ sudo service ntp stop
$ sudo ntpdate
10 Aug 20:33:53 ntpdate[8371]: no servers can be used, exiting
$ sudo ntpdate-debian
1 Apr 17:25:24 ntpdate[8383]: step time server a.b.c.d offset 83278265.128578 sec
$ sudo service ntp start

As you can see, after stopping ntp service, ntpdate is still unable to run, but ntpdate-debian finally could set the correct date.

How can I change the below configuration to let the "ntp service" do its job automatically in the background?

driftfile /var/tmp/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
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
pool 0.europe.pool.ntp.org iburst
pool 1.europe.pool.ntp.org iburst
pool 2.europe.pool.ntp.org iburst
pool 3.europe.pool.ntp.org iburst
server 0.debian.pool.ntp.org
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict ::1
restrict source notrap nomodify noquery

What's wrong with my configuration? It even contains "0.debian.pool.ntp.org", which if I run manually works:

ntpdate -q 0.debian.pool.ntp.org
  • 1
    Further to the 2 answers, ntp has mainly been superseded by ntpsec. Commented Apr 2, 2023 at 11:58

2 Answers 2


You did not mention your version of Debian, but it seems to be Debian 10 (buster, currently "oldstable") or older. Since the main developer of the NTP suite (David L. Mills, age 84) retired, the status of the NTP code stagnated.

By the release of Debian 11, the latest upstream releases of both ntpdate and ntpd both were quite old and had several known security vulnerabilities, so Debian 11 wound up recommending the newer NTP implementation chrony instead. However, the classic ntpdate and ntpd are still available in Debian 11 too.

The only configuration file used by /usr/sbin/ntpdate is /etc/ntp.keys. Everything else must be specified on the command line, or in a script that is invoking /usr/sbin/ntpdate.

ntpdate-debian is a script that reads /etc/default/ntpdate and uses the time servers configured there.

The /etc/ntp/ntp.conf is for the NTP service (the ntpd process) only.

The failure of your ntpdate and sudo ntpdate without any other parameters seems normal and expected, as ntpdate would not know which server(s) to use when invoked like that.

Since both ntpdate and ntpd (= the ntp service) attempt to use the local UDP port 123, you cannot run both at the same time: it must be one or the other. That explains why your sudo ntpdate only worked after stopping the NTP service. And since the UDP port number is less than 1024, you cannot use that port without root privileges.

You did not show the contents of your /etc/default/ntpdate, so I can't guess which server(s) were used by it, but it seems to have worked after you stopped the NTP service. Running ntpdate without parameters does not specify which NTP server to use for synchronization, that failure was expected, even with sudo.

The NTP service failed to sync your clock because your system time was way out of true (several years!). By default, the NTP service (= the ntpd process) has a safety limit of, I think, something like +/- 1000 seconds: if the system time is out more than that, ntpd won't even attempt to fix it, because huge time jumps can cause problems with databases and other software that cares about the time. It will be the responsibility of the sysadmin to get the system clock to something roughly resembling current time, and then ntpd will be able to sync it.

If ntpd is started with the -g option, the first adjustment (only!) can be larger than the 1000-second safety limit. If your system uses Debian 10's defaults, /etc/default/ntp should have NTPD_OPTS='-g', which tells ntpd to use this option when started as a service. If you had that configuration, then just stopping and restarting the NTP service (sudo service ntp stop; sudo service ntp start) would have been enough to fix your time... unless there is some ultimate sanity check in ntpd that makes it refuse to make adjustments larger than one year or so.

(This default setup can actually make Debian 10's NTP service a bit dangerous to restart if you have time-sensitive applications running. Other distributions solve this issue by having two separate services: a one-shot ntpdate service that runs early in boot, and can make large adjustments if needed, and then ntpd that starts afterwards and is restricted to gradual adjustments only; that makes the ntpd service safer to restart at any time.)

Assuming that your system is using PC-like x86 hardware with a functioning battery-backed real-time clock (RTC, also the "BIOS clock"), you should perhaps do a sudo hwclock --systohc --utc after sudo ntpdate-debian, to get the RTC to the correct time. If the RTC works even with poor accuracy, it should keep the system time within ntpd's safety limits while the system is shut down, so ntpd would be able to fully synchronize it.

  • The system is a hw-clock-less system, so at every boot, it starts with default 2020.01.01 00:00:00. That causes a huge difference for the first time. I now ended up with systemd-timesyncd, it's updating my clock now, without any further mistery :) ntpd service shall read /etc/ntp.conf but it obviously doesn't do that. So I chosed a simpler path with timesyncd for now.
    – Daniel
    Commented Apr 2, 2023 at 7:00
  • 1
    systemd-timesyncd is just a SNTP client, not full NTP... but if it works for you, that's fine. For ntpd, you would want to add tinker panic 0 as the first line of ntp.conf to remove the safety check, and/or ensure that NTPD_OPTS='-g' is present in /etc/default/ntp which should do pretty much the same.
    – telcoM
    Commented Apr 3, 2023 at 8:38

Crosscheck the config file you are adding the servers into.

ntpdate does not use the 'ntp.conf'.

Also, crosscheck if you have an 'ntpd' service already running. That might be creating a conflict.

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Apr 2, 2023 at 8:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .