I use a Raspberry Pi 3 and need to update the time via ntp after reboot the system.

It should be updated via wifi with dhcp. Generally it works, but the synchronisation needs approx. a half an hour and I don’t understand why.

When I want to start the ntp service manually with

>>sudo /etc/init.d/ntp restart

It says „ok“, but the system does nothing - the wrong time is still on the RTC.

Do you have an idea, what could be the problem?

Another information is, that the Pi runs in the read only mode...but if its not working without write access it wouldn’t be updated after an half hour, isn’t it?

More details:

To complete my problem here is the ntp.conf:

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

Driftfile /var/lib/ntp/ntp.drift

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


Server 0.de.pool.ntp.org iburst
Server 1.de.pool.ntp.org iburst
Server 2.de.pool.ntp.org iburst
Server 3.de.pool.ntp.org iburst

Server #local clock
Fudge stratum 10


To expand my explanation about my project. I want to use the Pi as a NTP server. The first problem was that the RTC „runs away“ after a reboot or when the Pi is turning off - especially for a longer time. That’s why I had the idea, that the Pi should be a NTP client at the first time to set the RTC and after that the Pi needs to be a NTP server for the device, which is connected via ethernert with the Pi. So I connected the Pi via Wifi to get the current time. As I told already generally it works, but it takes too much time.

Then I wanted to make the synchronisation manually with this command I posted before. My idea was to do this as a cronjob, but there is the next problem: 1. the Pi ignored the command; 2. the cronjob is ignored, too, or deleted after a reboot.

But I want to go step by step and the first problem I want to solve is to decrease the sync time.

I hope you have a better overview now about my situation....

Do you need more details?


Okay, so I have now the solution I want, BUT there is a behavior, which I don’t understand. The configurations were correct. However, I use the onboard WiFi to synchronize the system time via a NTP server, which I configured in the ntp.conf. I use the ethernet (wired LAN) to be the NTP server for the wired device to the RPi. Here the IP settings:

WLAN (DHCP): 192.168.1.x
Ethernet (static):

I put both interfaces in different networks, because otherwise just one connection would be work - But why actually? And this is the main problem, why the synchronization had taken so long time. When I comment out the line with the local clock


Then the synchronization over the network works immediately... Why it is happens?

  • 1
    How does your /etc/ntp.conf look like? You may want to add that to your question. Check if you have the iburst option in the lines starting with server or pool which should speed up the initial time sync.
    – Thomas
    Commented Jan 13, 2018 at 9:25
  • You need to edit the question to provide that, and to also give answerers actual numbers. State how far adrift your clock is at bootstrap. Show them the logs of your ntpd service over the service restart.
    – JdeBP
    Commented Jan 13, 2018 at 10:19
  • @JdeBP If it a rpi, it will be very adrift, as it does not have a RTC. See my answer. Commented Jan 15, 2018 at 14:19
  • It is a PiFace brick with a CR1220 battery
    – Susanne
    Commented Jan 15, 2018 at 16:37
  • The questioner has just told you that it does have an RTC. (-:
    – JdeBP
    Commented Jan 15, 2018 at 17:08

3 Answers 3


The rpi does not have an RTC, and so it boots always in 1 Jan 1970 - the time to put the server and NTP synchronised slowly and incrementally is bigger; so by default NTP does not start operating normally until the difference between NTP and the system is corrected.

I would add to your ntp.conf file as the first line (it has to be the first line):

tinker panic 0

This setup is advised for VMs and iOTs devices.

tinker panic - Specifies the panic threshold in seconds with default 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted.

I would also consider buying an RTC, as it is cheap, especially if you intend to have projects without Internet connectivity. see hwclock can't open rtc file

  • Thanks a lot for the fast answer Okay, I bought already a RTC, sorry I forgot to tell. And I tried it with the „tinker panic 0 option“ and it doesn’t make it faster.
    – Susanne
    Commented Jan 15, 2018 at 16:08
  • use -g optin - panicgate with ntpd daemon. Don't touch tinker
    – wick
    Commented Feb 11, 2023 at 18:38

This problem was solved for me by adding "flag1 1" to the fudge lines in /etc/ntp.conf. We are using GPS to set the time. If the system clock battery gets run down the system will not start up with the right time. We need NTP to quickly fix it. Here is our /etc/ntp.conf file:

# "flag1 1" means skip the difference limit check and fix the time even if it is far off.
# If the battery for the system clock fails the system clock will start with a default time.
# The date will be years off, more than the sanity check limit, we need for ntp to correct the time anyway.
# GPS Serial data reference
server minpoll 4 maxpoll 4 true
fudge time1 0.0 refid GPS flag1 1

# GPS PPS reference 
server minpoll 4 maxpoll 4 prefer true
fudge refid PPS flag1 1

driftfile /var/lib/ntp/drift

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Allow unrestricted acces from the localhost
restrict mask
restrict -6 ::1

# 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 disable
filegen clockstats file clockstats type day enable

I found this solution here: NTP Documentation

  • Wrong link for NTP Documentation?
    – Noman_1
    Commented Sep 7, 2023 at 8:33

Use the ntpdate utility as a once-a-boot utility to get the clocks close enough for ntpd to manage.

If your distro has it, check the chrony RPM package; it is easier to manage than classic NTP.

  • More complicated, as you have to make sure ntpdate runs before ntpd goes up. Commented Jan 15, 2018 at 14:17
  • Okay, I‘m not sure if I understand it clearly. What is the RPM package and how can I get sure that the ntpdate runs before ntpd? And for testing I made just a drift of 20 min to the current time.
    – Susanne
    Commented Jan 15, 2018 at 16:02
  • You don't really need ntpdate. There's the fake-hwclock package already installed as a standard part of RPi distributions to get the clock correct to a reasonable approximation prior to NTP kicking in. Commented Jan 15, 2018 at 16:05
  • My fake-hwclock is really close to the real time. Because when I put on the write access the fake-hwclock is updated before the Pi shuts down. So now is approx. a 2h drift
    – Susanne
    Commented Jan 15, 2018 at 16:34

You must log in to answer this question.

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