FPP 9.4: ntpd fails to set time on boot

[jonathanfink]

Please answer the following:

FPP Version and Hardware:
FPP 9.4 running on Raspberry Pi4

Describe the bug and Steps to reproduce:
A clear and concise description of what the bug is and the steps to be taken to reproduce.

1. Boot the RaspberryPi
2. Check the date/time
3. Find that it is September 11, 2025

Expected behavior:
ntpd should set the date/time correctly as Pi does not have an RTC

Additional context:
This bug appears to happen because the time offset between what the OS believes is the time (September 11, 2025) is greater than 1000 seconds.

I worked around by modifying /etc/ntpsec/ntp.conf to include: "tinker panic 0"

After this hack, ntpd sets the correct time. I believe a better fix would be to invoke ntpd with the "-g" flag.

[OnlineDynamic]

@jonathanfink on your system are you not seeing the -g flag already in place?

On mine I see:

root@DEV-Pi5:/opt/fpp# ps aux | grep ntpd | grep -v grep
ntpsec 5964 0.0 0.4 17720 16600 ? SLs Jan05 0:06 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec

[cybercop23]

Running 9.4 on a K2Pi (no RTC) rebooted it and after a few seconds the time showed up correctly.
I also have the -q in the ntp command as shown above.

[jonathanfink]

fpp@fpp:~ $ date
Thu Sep 11 08:12:07 PM EDT 2025
fpp@fpp:~ $ ps -ef | grep ntp
ntpsec    1613     1  0 20:11 ?        00:00:00 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
fpp       1761  1638  0 20:12 pts/0    00:00:00 grep --color=auto ntp
fpp@fpp:~ $ sudo service ntpsec status
● ntpsec.service - Network Time Service
     Loaded: loaded (/lib/systemd/system/ntpsec.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-09-11 20:11:51 EDT; 58s ago
       Docs: man:ntpd(8)
    Process: 1610 ExecStart=/usr/libexec/ntpsec/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 1613 (ntpd)
      Tasks: 1 (limit: 2795)
        CPU: 176ms
     CGroup: /system.slice/ntpsec.service
             └─1613 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec

Sep 11 20:11:51 fpp ntpd[1613]: INIT: Built with OpenSSL 3.0.9 30 May 2023, 30000090
Sep 11 20:11:51 fpp ntpd[1613]: INIT: Running with OpenSSL 3.0.17 1 Jul 2025, 30000110
Sep 11 20:11:51 fpp ntpd[1613]: NTSc: Using system default root certificates.
Sep 11 20:11:52 fpp ntpd[1613]: DNS: dns_probe: falconplayer.pool.ntp.org, cast_flags:8, flags:121
Sep 11 20:11:52 fpp ntpd[1613]: DNS: dns_check: processing falconplayer.pool.ntp.org, 8, 121
Sep 11 20:11:52 fpp ntpd[1613]: DNS: Pool taking: 23.186.168.130
Sep 11 20:11:52 fpp ntpd[1613]: DNS: Pool taking: 66.244.16.123
Sep 11 20:11:52 fpp ntpd[1613]: DNS: Pool taking: 23.186.168.125
Sep 11 20:11:52 fpp ntpd[1613]: DNS: Pool taking: 205.233.73.201
Sep 11 20:11:52 fpp ntpd[1613]: DNS: dns_take_status: falconplayer.pool.ntp.org=>good, 8
fpp@fpp:~ $ date
Thu Sep 11 08:12:54 PM EDT 2025

[jonathanfink]

From Gemini:

"For a system without a hardware RTC, the first NTP update sets the system clock from an NTP server once network connectivity is established, but relies on software solutions like fake-hwclock (Debian/Ubuntu) or kernel timers to maintain time across reboots by saving the time at shutdown and restoring it at boot. The critical step for immediate syncing is ensuring the NTP client (like ntpd or chronyd) starts early and applications wait for it to sync, often using ntp-wait or systemd dependencies, to prevent issues with the default "Jan 1, 1970" time."

I think there is another reported issue affected by a clock that is not updated before FPP starts. I think some gating must be added to prevent FPP itself from starting before NTP has stabilized the time.

[OnlineDynamic]

just put a commit on master to fully stop ntpd on network up and force a one time ntpd large time sync before continuing normal service - @jonathanfink could you please test if that has helped in your environment

[jonathanfink]

It's working better, as by the time I can log into ssh and check the time it has already been updated but it appears scheduler is still starting before ntp updates the time.

Scheduler Status:
Playing 'new years 2026'
Playlist Started at:
Thu Sep 11
08:11 PM
Graceful Stop at:
Thu Sep 11
10:00 PM

I can workaround this reasonably well by setting the start date for my schedule to September 12 but I'm sure this will still trip others up.

[OnlineDynamic]

could you give it another test for me please @jonathanfink - I have made another change which now makes fppd wait for the time sync to complete before starting - hopefully that gives us the gated approach to stop the scheduler getting carried away

[OnlineDynamic]

had to push yet another change so I didn't break fpp devices with no network - hopefully still works for your scenario

[jonathanfink]

First cold boot after change worked perfectly. I powered off and repeated. This time it's stuck waiting:

PING falconplayer.pool.ntp.org (198.60.22.240) 56(84) bytes of data.
64 bytes from clock.xmission.com (198.60.22.240): icmp_seq=1 ttl=55 time=71.5 ms
64 bytes from clock.xmission.com (198.60.22.240): icmp_seq=2 ttl=55 time=77.3 ms
64 bytes from clock.xmission.com (198.60.22.240): icmp_seq=3 ttl=55 time=73.0 ms
^C
--- falconplayer.pool.ntp.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 71.505/73.915/77.289/2.457 ms
fpp@fpp:~ $ sudo service ntpsec status
○ ntpsec.service - Network Time Service
     Loaded: loaded (/lib/systemd/system/ntpsec.service; enabled; preset: enabled)
     Active: inactive (dead) since Thu 2025-09-11 20:11:47 EDT; 5min ago
   Duration: 2.718s
       Docs: man:ntpd(8)
    Process: 807 ExecStart=/usr/libexec/ntpsec/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 844 (code=exited, status=0/SUCCESS)
        CPU: 220ms

Sep 11 20:11:47 fpp ntpd[844]: IO: failed to init interface for address fe80::dea6:32ff:fead:8ebf%3
Sep 11 20:11:47 fpp ntpd[844]: IO: new interface(s) found: waking up resolver
Sep 11 20:11:47 fpp ntpd[844]: DNS: dns_probe: falconplayer.pool.ntp.org, cast_flags:8, flags:121
Sep 11 20:11:47 fpp ntpd[844]: DNS: dns_check: processing falconplayer.pool.ntp.org, 8, 121
Sep 11 20:11:47 fpp ntpd[844]: DNS: dns_check: DNS error: -3, Temporary failure in name resolution
Sep 11 20:11:47 fpp ntpd[844]: DNS: dns_take_status: falconplayer.pool.ntp.org=>temp, 3
Sep 11 20:11:47 fpp ntpd[844]: ERR: ntpd exiting on signal 15 (Terminated)
Sep 11 20:11:47 fpp systemd[1]: Stopping ntpsec.service - Network Time Service...
Sep 11 20:11:47 fpp systemd[1]: ntpsec.service: Deactivated successfully.
Sep 11 20:11:47 fpp systemd[1]: Stopped ntpsec.service - Network Time Service.

I wonder if this is the root cause of the initial failure: a race condition with DNS starting vs ntpd?

[jonathanfink]

I've cycled a few more times... the latest problem is very intermittent: around 10% of cold boot cycles show the problem.

[OnlineDynamic]

just realised some of my change won't have copied across to your system files as I forgot to put the upgrade script in place... if you pull in the latest commits on master from the UI hopefully that will install it correctly

[jonathanfink]

Ironically, I was doing "sudo git pull && sudo make" so I would have missed copying the script as well. I pulled again and copied the script. 10 cycles without a failure. 🤞