I am running raspbian wheezy, upgraded to all the latest packages. The only custom package installed on it is Oracle's Java 8, everything else and its configuration is stock.

Yesterday I noticed that the rpi time was wrong (after a short power failure). I started digging and found out that the NTPd service is not updating the local time. This is most likely only a recent problem since I had power failures before and never noticed problems with time.

The NTP daemon seems to be running. When I stop the service and run ntpd manually

sudo ntpd -gq

It is supposed to update the time and exit. But it never does. Just continues running without actually doing anything.

/var/log/syslog logs the following:

May  5 07:20:51 autohome ntpd[4111]: ntpd [email protected] Fri May 18 20:30:57 UTC 2012 (1)
May  5 07:20:51 autohome ntpd[4111]: proto: precision = 1.000 usec
May  5 07:20:51 autohome ntpd[4111]: Listen and drop on 0 v4wildcard UDP 123
May  5 07:20:51 autohome ntpd[4111]: Listen normally on 1 lo UDP 123
May  5 07:20:51 autohome ntpd[4111]: Listen normally on 2 eth0 UDP 123
May  5 07:20:51 autohome ntpd[4111]: peers refreshed
May  5 07:20:51 autohome ntpd[4111]: Listening on routing socket on fd #19 for interface updates

Networking seems to be working properly and the default NTP servers in ntp.conf seem to up. The ntp.conf is standard (I only disabled ipv6):

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

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

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

# 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 ::1

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

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth

The ntpd version that comes with raspbian is compiled without debug, so ntpd -d doesn't work. Any idea what can possible cause this?


4 Answers 4


Took me a while to figure out what is going on but after installing tcpdump, monitoring the network traffic and more carefully reading the fine print of NTPd docs, I realized that NTPd requires unrestricted access to UDP port 123 for both outgoing and incoming traffic.

Since this is not something I'm willing to do on my network, I uninstalled the ntp package and installed openntpd package (also in the repository) instead.

Two minutes later and everything was working like a clockwork.

  • 1
    This is false: "NTPd requires unrestricted access to UDP port 123 for both outgoing and incoming traffic." I would love to hear what fw rules you had in place that work with openntpd and not ntpd given the same basic config (list of servers/allowed clients).
    – dfc
    May 6, 2014 at 22:38
  • False? That is take directly from NTP site: support.ntp.org/bin/view/Support/TroubleshootingNTP check section 9.8. And you can check with packet sniffer that NTPd uses 123 as source port, openntpd uses high port numbers
    – danielv
    May 7, 2014 at 7:13
  • That statement is taken from the ntp "community edited support wiki." The statement is too broad and confusing to newcomers. I have configured a lot of ntp servers that sat behind firewalls that only allowed traffic to and from my ntp and select upstream servers.
    – dfc
    May 7, 2014 at 12:06
  • With all respect, until proven otherwise, I won't disregard what's written on the officially sanctioned support guide, wiki or not, based on a comment from a random guy on the internet. And fact remains, NTPd uses UDP port 123 as both source and destination ports, which may be problematic in various routers to port forward or even simply blocked by certain ISP's. openntpd, on the other hand, uses high ports as source which is the more correct behavior and removes any need of fiddling with the firewall/NAT. Bottom line, as configured, packets don't return to NTPd while openntpd just works.
    – danielv
    May 7, 2014 at 12:40
  • FWIW I had switched to OpenNTPd and after some time switched back (which is a PITA). OpenNTP is way to chatty. It basically spammed my syslog full with what a fine job it was doing, every 60 seconds... And documentation is unclear at best. No option to reduce chattyness was to be found. On Raspbian, disk space is scarce, I don't need spam there.
    – Sherlock70
    Jun 18, 2020 at 10:11

Also had problems with ntpd syncing, got an offset of -7294 seconds after reboot and ntpd was not able to sync up. Think the limit for ntpd is 127 seconds. Had the same problem on raspberrypi and bananapi. The solution was the same on both. Here i am using Raspian_For_BananaPi_v3.1 on a BananaPi. The reason for the -7294 sec offset was that the /etc/init.d/ntp script was starting the /var/lib/ntp/ntp.conf.dhcp as the config file for ntpd (-c), this file was using as timerserver. Which is my internet modem with a timeserver which had -7294 seconds offset. Complained to my internet provider, but has not got any feedback yet.

Just commented out three lines in /etc/init.d/ntp to fix the problem:

#  if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
#     NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
#  fi

then ntpd will use the default config file /etc/ntp.conf.

Then I just changed from debian to local (no) pools in /etc/ntp.conf:

# pool: <http://www.pool.ntp.org/join.html>
server 0.no.pool.ntp.org iburst
server 1.no.pool.ntp.org iburst
server 2.no.pool.ntp.org iburst
server 3.no.pool.ntp.org iburst

did a reboot and ntpd started to work.

bananapi@Banana2 ~ $ sudo ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
+ntp2.interpost.   2 u   66 1024  373   15.085   -1.769   2.660
*ntp-ext.cosng.n    2 u   88 1024  377   13.929   -3.778   4.319
+2a02:20c8:1981:    2 u 1021 1024  377   12.678   -2.927   2.763
-ntp1.enuv.eu   2 u  194 1024  377   11.598    6.200 106.058

The ntpd deamon is using the timeserver with a * in front, with 3.778 ms offset. It will take some hours before the offset is below 10 ms offset.


I had the same problem, which was fixed by re-setting the Time Zone using raspi-config. I had set the Time Zone correctly the first time the Raspberry Pi booted, but for some reason it forgot/ignored it. Now it automatically updates the time on boot, if connected to the internet.

  1. sudo raspi-config
  2. Select Internationalisation Options
  3. Select I2 Change Timezone
  4. Select your Geographical Area
  5. Select your nearest City
  6. Select Finish
  7. Select Yes to reboot now

Well I had similar problems on my pies which kept bugging me for a while..on first one I kept manualy setting time ( i had no net connection on it) on the other solution came when I reconfigured time zones and rebooted...alternatively you could install (hardware) real time clock module if you can find it..Did you notice different time stamps in logs?And sorry if the answer is not concise enough...

  • Also you can try adding DAEMONS=(!hwclock ntpd)in /etc/rc.conf and reboot to see if that does the trick..
    – zsn
    May 5, 2014 at 7:24
  • Thanks. Manually setting is not an option. This rpi runs home automation software and accurate time is critical (getting stuck without hot water because inaccurate clock is really annoying). Hardware clock is possible, I guess, but I'd really like to try and solve the NTPd problem first. This is what NTPd it's supposed to do and it was working until recently.
    – danielv
    May 5, 2014 at 7:27
  • Ok...try that line in /etc/rc.conf and/or check timezones, see if that helps...
    – zsn
    May 5, 2014 at 7:34
  • What do you mean by "check timezones"? Also, there is no /etc/rc.conf in my rpi.
    – danielv
    May 5, 2014 at 8:00
  • sorry, /etc/rc.local..;by timezones I mean selecting them again in raspi-config..also you can check /etc/ntp.conf file to make sure it is configured( which servers does it use..? )
    – zsn
    May 5, 2014 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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