83

The Raspberry Pi lacks a hardware clock. How do I force NTPD to update date/time immediately after every boot?

I'm running Raspbian and the Raspberry Pi is connected using an Ethernet cable.

9
  • 1
    Mine already does that out of the box. What disto are you using?
    – Gerben
    Jul 1, 2013 at 12:05
  • Raspbian Wheezy
    – Alessandro Da Rugna
    Jul 1, 2013 at 13:16
  • 1
    @Thorb Pi is connected with ethernet cable / dhcp. It simply does not get a valid date after booting, it takes a while (10 to 45 minutes)
    – Alessandro Da Rugna
    Aug 5, 2013 at 7:31
  • 1
    It will do it automatically, after a couple of minutes. Be sure you have set it to use the Master Clock at the National Bureau of Standards, time.nist.gov as described here: raspberrypi.stackexchange.com/questions/68811/…
    – SDsolar
    Nov 4, 2017 at 8:03
  • 2
    Seems that no one has yet answered this question satisfactorily - i.e. how to sync time via NTP after a boot (i.e. without rebooting).
    – Rebroad
    Jan 15, 2020 at 14:38

16 Answers 16

Reset to default
54

After searching around, this method worked for me. As you know, the Raspberry Pi 3 has NTP disabled by default. So by just typing this, the NTP support will be enabled:

sudo timedatectl set-ntp True

Check result with timedatectl status

In case of warning, you may have to run sudo timedatectl set-local-rtc true too.

2
  • 1
    Thanks, this finally helped me out, and seems to be the proper way, despite previous answers.
    – CharlieS
    Jun 30, 2017 at 1:12
  • 1
    That is the best answer, helped me a lot. You can use 'sudo' to avoid typing your password (useful for scripts that run it). What is the purpose of the seconds command? set-local-rtc
    – Arad
    Nov 29, 2017 at 13:38
45

Do an apt-get install ntpdate .

ntpdate will run when an Ethernet interface is brought up, and set the time from an ntp server (see /etc/default/ntpdate).

If ntpd is running, ntpdate will do nothing, however ntpdate will run prior to ntpd at bootup - so this should work out to set the time at bootup as long as there's an Ethernet connection.

4
  • 1
    stock Raspbian will have all this already.
    – scruss
    Jul 4, 2013 at 1:27
  • 10
    @scruss mine didn't. (2013-02-09 wheezy rasbian)
    – Pete Kirkham
    Feb 23, 2014 at 14:14
  • If it is set up correctly it will do it automatically - although it may take a few minutes.
    – SDsolar
    Oct 21, 2017 at 20:24
  • "Ethernet" is a misnomer here. A valid connection to a specified server is required (not necessarily Ethernet).
    – pds
    Nov 29, 2021 at 9:51
44

If your clock is way off, you may need to force ntp to sync by doing:

sudo /etc/init.d/ntp stop
sudo ntpd -q -g
sudo /etc/init.d/ntp start
5
  • Could you please visit raspberrypi.stackexchange.com/questions/47542/… ? I have posted details there.
    – Pygmalion
    May 18, 2016 at 20:05
  • 3
    This was absolutely the solution to my problem, but I found it to be temporary until I rebooted. Eventually I caught an error in the shutdown that it couldn't update the hwclock because the hw clock had a future date (no idea how that happened). But the solution was a hwclock update force. That forced the update to the fake hardware clock and then on boot the time was at least close to the current so ntp could do it's job normally.
    – Piwaf
    Sep 20, 2016 at 18:36
  • It is possible to pass those arguments to the ntpd daemon along with its configuration file. Don't use /etc/ntp.conf as it is the wrong configuration file and is likely to be overwritten at boot. IIRC you should be able to put these startup parameters in /etc/default/ntpd.
    – user29510
    Feb 23, 2017 at 16:55
  • 1
    /etc/init.d/ntp does not exist
    – Rebroad
    Jan 15, 2020 at 14:39
  • Indeed - ntp is no longer installed by default (since stretch in 2017). Here's some background on that change if you're interested.
    – Seamus
    Apr 29, 2021 at 6:32
27

This question is apparently being "recycled" for some reason, and so it seems appropriate to recycle some old answers also :)

The year is now 2023...

This question was asked in 2013. ntpd was the timekeeping software included in the Raspbian distribution at that time (wheezy). However, that changed with the stretch distribution in 2017 when systemd-timesyncd replaced ntpd. The reasons for this change, and some of the technical tradeoffs were discussed in this old answer for those who are interested in such things.

With respect to the question here, perhaps the most salient point in the current environment (bullseye & onward, post-systemd) is this: If you decide to install ntpd (now ntpsec) under your current Raspbian distribution, you will be required to REMOVE systemd-timesyncd. IOW, Debian has declared other timekeeping services in conflict at the apt package level. This method of conflict resolution required Debian to break systemd-timesyncd out as a separate package (apart from systemd), and declare a virtual package called time-daemon. (See REFERENCE)

Note that this method of conflict resolution is (may be) unique to Debian-based distros such as raspbian, and has been fairly recently developed. During an earlier time (e.g. Aug 2018), systemd-timesyncd would "excuse itself" by checking for the presence of other NTP daemons. Earlier versions of the config file for systemd-timesyncd (listed via systemctl cat systemd-timesyncd) included the following ConditionFileIsExecutable statements:

# Under earlier (e.g. Aug 2018) releases of raspbian:
$ systemctl cat systemd-timesyncd

Note the last few lines of the ouput listing:

# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

In other words: systemd-timesyncd checks to see if any of these alternative time services are running on your system, and if so, politely defers to them for providing your timekeeping services. It is left to the reader to decide whether the Debian method of conflict resolution is superior or inferior to using the ConditionFileIsExecutable statements.

"force" ntpd to update after boot?!

This was the OP's question. The answer (in 2023) hasn't changed: It shouldn't be necessary to do this on any RPi system - unless someone has changed the default configuration! You can verify this as follows:

$ timedatectl
               Local time: Wed 2021-01-13 00:25:33 GMT
           Universal time: Wed 2021-01-13 00:25:33 UTC
                 RTC time: n/a
                Time zone: Europe/London (GMT, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Note two items:

  1. System clock synchronized: yes
  2. NTP service: active

Item 1. tells you your system clock is synchronized with whatever the default time source is, and Item 2. is nearly true in that RPi uses the SNTP protocol by default instead of NTP (REF); i.e. this means RPi has a time source, and it is using it.

I think that's all that's needed for an up-to-date answer for 2023, except this: read man timedatectl to learn more about its capabilities.

11
  • 4
    System clock synchronized: no
    – Arrow_Raider
    Jan 22, 2021 at 23:29
  • 2
    Actually, the statement that Raspian(Debian) will "do the right thing" and "it just works" are at odds with one another; if the NTP daemon is installed in the '/usr/local/sbin' directory---which it is and should be if you build it yourself---then "it DOES NOT work". You must find the file that controls that list and add the correct entry.
    – Steven High
    Mar 15, 2021 at 0:06
  • 1
    @Seamus, When I attempted to add my own explanation, I had my comment excised and got yelled a for going "off-topic". The Best Practices way of installing local system binaries---an NTP built from sources, say---is to install the binaries in '/usr/local/sbin' and '/usr/local/bin'; the timesyncd does NOT search '/usr/local' for installed binaries. So the fix involves adding the '/usr/local/sbin/ntpd' and so on, to the config files, which I can't place in a comment. I would LOVE to post an answer here on how to do that.
    – Steven High
    Mar 20, 2021 at 23:51
  • 1
    "do the right thing". "it just works". The year is 2021 and it is still not working. I had my pi connected to the guest wlan of the router and it didn't work ("System clock synchronized: no"). Switching to the the private wlan resolved it.
    – Markus
    Jun 3, 2021 at 12:23
  • 1
    @Seamus it might be worth mentioning that the pi has to be connected to the internet (obviously) and that the router may not block UDP port 123, which is used for ntp. This port will most likely not be blocked in a default configured router. In my case (using default configured guest wifi) this port was blocked. Maybe add a short command to the post on how to check whether UDP port 123 is reachable. Unluckily I couldn't find a method to test this yet. I tried nc -z -v -u google.com 123 which always succeeds.
    – Markus
    Jun 4, 2021 at 13:28
20

If you set the Time Zone in raspi-config the Raspberry Pi will automatically update 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
4
  • I2 Change Timezone option doesn't exist any more
    – mrded
    Jun 25, 2019 at 21:59
  • It does exist, at least in Raspbian Buster.
    – PotatoBox
    Jan 11, 2020 at 17:45
  • 1
    "Internationalisation Options" is now called "Localisation Options"
    – Adrian
    Feb 26, 2020 at 19:01
  • 1
    "nearest city" is not the proper way. you need to select the city where your time zone belongs, which may be the nearest, or not...
    – logoff
    Jan 7, 2021 at 9:58
13

See forum post Time does not sync on Pi 3 and with official dongle.

ntpd emits IP/UDP packets with the ToS field set to 0xc0. So that is quite similar to the other issue I (and many others) have with Raspberry Pi3 when operated over a Wi-Fi internal interface.

As a workaround, add the command

/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p udp --dport 123 -j TOS --set-tos 0x00

to the file

/etc/rc.local

before the exit 0 line. Next, reboot and check.

1
  • 1
    I had the same issue as Iinstalled the RPi3 I got for XMas,and you solved my problem. Great !!!
    – jfmessier
    Dec 27, 2016 at 1:49
8

It should already be updating the time. The NTPD server should start just after the swap file and before SSHD.

Check your /etc/ntp.conf file to make sure it is configured.

It should list at least one server. I use time.nrc.ca for my server.

Manual page for ntp.conf is here: http://linux.die.net/man/5/ntp.conf

3

My son's Rasberry Pi would not update the time out of the box and after trying all the suggestions above I could get it to update manually but not automatically. Finally after looking elsewhere as well without success, I found that the ntp.conf file that came with the Rasberry Pi had the following lines commented out:

#restrict 127.0.0.1
#restrict ::1

I used

sudo nano /etc/ntp.conf

in the terminal to edit the ntp conf file to now be: 

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

That solved the problem for us. It updates with both the WiFi and the ethernet cable. I don't know if it would update with WiFi without the change to rc.local suggested above, as by the time I found the solution above I had already made that change and I have not undone it.

3

You don't need to use ntp to solve the issue. There is a script that reads the date from a server and you only need set the date to be the result of that script (your Raspberry Pi needs to be connected to the internet). Then, you need to run that command at startup.

Step1: Retrieve the date from a server.

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

Step2: Run the command at startup by adding it to the file /etc/rc.local (Worked on Ubuntu 16.04).

sudo gedit /etc/rc.local

CREDITS:

1- https://askubuntu.com/a/655528/572294

2- https://askubuntu.com/a/1199/572294

2
  • 1
    You may not need to use ntp but you should. It's better, faster, more accurate, and the industry standard. Don't make up your own weird things when good standards exist please.
    – Cameron Tacklind
    Mar 5, 2020 at 1:13
  • It doesn't help much if your RasPi is running 24/7.
    – Ingo
    Mar 26, 2020 at 12:58
3

I had a similar problem with a Pi not syncing. None of these solutions worked. Turns out my network environment was blocking the NTP port (123). The solution for me was

sudo apt install htpdate

taken from: https://www.raspberrypi.org/forums/viewtopic.php?t=222236

Which updates the system clock through HTTP calls instead.

1
  • Yes, this works nice in my work environment, where most ports (other then 80) are blocked.
    – Aoki Ahishatsu
    Nov 12, 2021 at 12:02
2

I found the timedatectl application to help me when I was having a similar issue. It's installed by default and '--help' gives a pretty good and simple overview of how to use the tool.

Note: make sure your timezone is set properly, which this tool can do as well.

1

This is the approach I ended up taking. Many of these answers seemed to indicate things that just didn't check out when I looked at my Raspian system:

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

I had nothing that appeared in logs indicating that timedatectl was doing anything, or that ntp was syncing on the NIC's up state, or that NTPD was even installed/configured.

In the end I merely added this to my /etc/rc.local:

$ cat /etc/rc.local
logger "Beginning force syncing NTP..."
service ntp stop
ntpd -gq
service ntp start
logger "Finished force syncing NTP..."

And installed ntp:

$ sudo apt-get install ntp

Which results in this in /var/log/syslog:

Aug  5 09:10:20 pi-hole ntp[526]: Starting NTP server: ntpd.
Aug  5 09:10:20 pi-hole ntpd[555]: proto: precision = 1.458 usec (-19)
Aug  5 09:10:20 pi-hole ntpd[555]: Listen and drop on 0 v6wildcard [::]:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 2 lo 127.0.0.1:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 3 eth0 192.168.1.85:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 4 lo [::1]:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 5 eth0 [fe80::f5ea:7663:4ec:784d%2]:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listening on routing socket on fd #22 for interface updates
Aug  5 09:10:21 pi-hole ntpd[555]: ntpd exiting on signal 15 (Terminated)
Aug  5 09:10:21 pi-hole ntp[661]: Stopping NTP server: ntpd.
Aug  5 09:10:21 pi-hole ntpd[674]: ntpd [email protected] Sat Mar 10 18:03:33 UTC 2018 (1): Starting
Aug  5 09:10:21 pi-hole ntpd[674]: Command line: ntpd -gq
Aug  5 09:10:21 pi-hole ntpd[674]: proto: precision = 0.625 usec (-21)
Aug  5 09:10:21 pi-hole ntpd[674]: Listen and drop on 0 v6wildcard [::]:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 2 lo 127.0.0.1:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 3 eth0 192.168.1.85:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 4 lo [::1]:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 5 eth0 [fe80::f5ea:7663:4ec:784d%2]:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listening on routing socket on fd #22 for interface updates
Aug  5 09:10:34 pi-hole ntpd[674]: Soliciting pool server 198.98.57.16
Aug  5 09:10:35 pi-hole ntpd[674]: Soliciting pool server 74.82.59.149
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 23.131.160.7
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 52.37.26.163
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 204.2.134.163
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 96.126.100.203
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 199.223.248.101
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 66.228.42.59
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 208.75.89.4
Aug  5 09:10:37 pi-hole ntpd[674]: Soliciting pool server 204.2.134.164
Aug  5 09:10:37 pi-hole ntpd[674]: Soliciting pool server 104.236.116.147
Aug  5 09:10:38 pi-hole ntpd[674]: Soliciting pool server 204.9.54.119
Aug  5 09:10:48 pi-hole ntpd[674]: ntpd: time set +6.769186 s
Aug  5 09:10:49 pi-hole ntpd[853]: ntpd [email protected] Sat Mar 10 18:03:33 UTC 2018 (1): Starting
Aug  5 09:10:49 pi-hole ntpd[853]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:114
Aug  5 09:10:49 pi-hole ntp[844]: Starting NTP server: ntpd.
Aug  5 09:10:49 pi-hole ntpd[856]: proto: precision = 0.625 usec (-21)
Aug  5 09:10:49 pi-hole ntpd[856]: Listen and drop on 0 v6wildcard [::]:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 2 lo 127.0.0.1:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 3 eth0 192.168.1.85:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 4 lo [::1]:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 5 eth0 [fe80::f5ea:7663:4ec:784d%2]:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listening on routing socket on fd #22 for interface updates
Aug  5 09:10:49 pi-hole root: Finished force syncing NTP...
4
  • Doesn't work on minimal raspbian: Failed to start ntp.service: Unit ntp.service not found. And ntpd doesn't exist either. The Pi definitely eventually gains time. (I'm looking into this because my HTTPS curls fail without -k when run prior to that)
    – Steven Lu
    Aug 9, 2018 at 18:32
  • @StevenLu - I'll update the A'er to include the install of ntp as well.
    – slm
    Aug 9, 2018 at 20:27
  • 1
    @StevenLu - apt-get install ntp
    – slm
    Aug 10, 2018 at 12:23
  • Or download the latest version from: link. This ensures your build is at the latest revision. You will want to use the hold argument for apt to keep Raspian from regressing to the build on the site.
    – Steven High
    Mar 15, 2021 at 0:14
0

I use the following on the default image to sync time without installing additional packages:

timedatectl set-local-rtc 0
timedatectl set-ntp 1
timedatectl status
0

I found this somewhere on the interwebs. Seems to work on Buster:

sudo timedatectl set-ntp false && sudo timedatectl set-time "$(date --iso-8601=seconds | cut -d "+" -f1 | tr T ' ')" && sudo timedatectl set-ntp true

I'm not sure if the intermediate command (set-time) is really needed.

0

Ok, so I did timedatectl and got everything looking fine.

But my raspberry pi never syncs clock when it is wrong. Typical problem scenario for me:

  • restore SD card from backup
  • boot is very slow
  • problems with ssh, ssl certificates
  • eventually realise the clock is wrong (showing the time approx when the backup was created).
  • try running various ntpd commands
  • eventually give up and set clock manually.

When I looked at it before, it seemed that some of the network startup was failing or not working properly because of the wrong clock, and this was interfering with clock sync.

What I would like is a way to force nptd to ignore all certificate expiry etc and just force an update of the clock, and for this to be something that reliably happens during boot, however far out the clock is.

I don't think this question is answered.

5
  • Have you disabled all of the systemd-timesyncd pieces? Once you've done that running sudo ntpd -g -q forces an update of the clock.
    – Dougie
    May 6, 2021 at 22:54
  • The problem is on startup. It doesn't start up properly if the clock is wrong. Lots of things don't work very well with a wrong clock, including remote login. So I still don't think the question is answered. I want a way that I can configure my RPi, so that on startup, however far wrong the clock is, it corrects it and performs a normal startup without interaction. It feels like a catch 22: - accurate-ish clock setting is needed for network startup. - Network startup is needed for accurate clock setting.
    – Dave
    Apr 30, 2022 at 22:44
  • That's the purpose of fake-hwclock to give you an approximate time of day until the RPi gets online and can sync to an NTP server. sudo ntpd -g -q is guaranteed to set the clock (if online) as it overrides the 1000s limit on clock drift. This stuff all works on my RPis and within a minute of booting the clocks are all correctly sync'd.
    – Dougie
    May 1, 2022 at 11:08
  • No it still doesn't work. I had to replace my SD card a few days ago. Clock was totally wrong and all ntp commands would not work until I set the clock manually.
    – Dave
    Jun 24, 2022 at 12:53
  • Important to clarify that the problem for me is on startup. I have various other devices including dhcp and bind running. It could be that these refuse to start up without approximately correct clocks, and that might be why I don't get a working network in order to set clocks. Perhaps the question in my case could be clarified as 'how do I automatically set the clock on startup when the device itself is the local dns server?
    – Dave
    Jun 24, 2022 at 12:58
0

I solved that in /etc/rc.local by adding at the end (before any exit 0):

sleep 10
ntpdate -u tempus1.gum.gov.pl > /dev/null

Sleep is needed because of starting Ethernet connection. Then immediately Pi synces date and time on each boot.

Check if you have rc.local service first (run at boot) as some of the recent systems lack it. If it does not exist - add it.

Also you can put the below in /etc/crontab:

59 */3  * * *   root    ntpdate -u tempus1.gum.gov.pl > /dev/null

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.