Reboots due to NTP host unsynchronized

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
S_Racing
New user
Posts: 6
Joined: 04 May 2020, 14:11

Reboots due to NTP host unsynchronized

#1 Post by S_Racing » 02 Dec 2022, 20:20

This morning around 8:00 am CET I noticed ALL my ESP Easy operated devices (8 x Wemos D1) to reboot every 10 to 15 minutes. The common theme was they all showed "NTP: NTP host (xxx.xxx.xxx.x) unsynchronized" obviously every time the eventhandler typically shows the date & time in the log. It seems after several (unsuccesfull) attempts to synchronize with the NTP server (my Fritzbox forwarding data from '2.europe.pool.ntp.org'), the ESP devices decide to initialize a reboot.

Afterwards, I can´t say if the issue was resolved by rebooting the Fritzbox or if any issue on the 2.europe.pool.ntp.org was meantime resolved, but what drives me around is:

- Is it a intended behaviour a ESP Easy device reboots every lets say 15 minutes because the NTP server is not accessible?
- In a first reaction I deactivated the 'Use NTP' Option in the ESP Easy advance settings, but this still bring up the rebooting issue. Any idea why not using NTP server still causes rebooting?
- Just curiosity: Anybody else had reboots around this time?

Regards
Marcus

User avatar
Ath
Normal user
Posts: 3416
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Reboots due to NTP host unsynchronized

#2 Post by Ath » 02 Dec 2022, 20:24

What exact build of ESPEasy do you installed on your ESP's (.bin filename please)?
/Ton (PayPal.me)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Reboots due to NTP host unsynchronized

#3 Post by TD-er » 02 Dec 2022, 20:33

It is by no means intended to reboot.
What could have happened is that the WiFi was unreachable for a while.
Depending on the used nr of tasks, which plugins and controller settings, the devices may have run out of memory.
MQTT messages take up quite a bit of memory when they are still in the controller queue waiting to be sent.

S_Racing
New user
Posts: 6
Joined: 04 May 2020, 14:11

Re: Reboots due to NTP host unsynchronized

#4 Post by S_Racing » 03 Dec 2022, 16:51

So far I used 3 different builds debending when the applications inside my SmartHome installation has been set up (Those ESP´s fully control and monitor the letterbox, refridgerator, aquarium, waterbed, etc...)
- ESP_Easy_mega_20200505_dev_ESP8266_4M1M
- ESP_Easy_mega_20211224_test_D_ESP8266_4M1M
- ESP_Easy_mega_20220616_normal_ESP8266_4M1M

The devices definitively had WiFi during that issue since I was able to check their status and log entries during the phase they had reboots. And they also sumitted their data during that time.

If it would have been only one/two devices, I would also say it was because of a memory issue - But 8 devices with different task/plugin/build setup showed multiple reboot issues at exactly the same timeframe and all of them logged "NTP: NTP host (xxx.xxx.xxx.x) unsynchronized" during that time. They worked without issue before and also show now issues now. By no means that could be a memory issue.

As said, I can´t say if the issue was resolved by rebooting my Fritzbox or if any issue on the 2.europe.pool.ntp.org server accessibility was meantime resolved, BUT lets assueme that a non-availability of a NTP server drives ESP devices into a regular every 15 minute reboot behaviour, would we call that something to be worried about? Probably yes considering the huge popularity of ESP Easy...

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Reboots due to NTP host unsynchronized

#5 Post by TD-er » 03 Dec 2022, 17:12

Do you happen to know the reboot reason?
Now that I think of it, this "NTP: NTP host (xxx.xxx.xxx.x) unsynchronized" error was added by me to log some odd situation, purely based on the specs of the NTP format. But never tested.
So it is very well possible the units try to access some un-allocated memory, or divide by zero, or something else exception wise.

User avatar
Ath
Normal user
Posts: 3416
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Reboots due to NTP host unsynchronized

#6 Post by Ath » 03 Dec 2022, 17:28

The reboots have probably been caused by the Watchdog, as the NTP code doesn't feed that (watch)dog during waiting for NTP time-out.
This can have multiple causes, either the NTP server didn't respond, or the WiFi was (terribly) slow.

You have a fixed NTP server address configured, does the Fritzbox buffer the NTP request, or is that a direct relay? In the latter case, most likely that NTP server was unreachable for some time.

ESPEasy NTP implementation doesn't need the NTP server to be set, if that field is empty ii just requests a response from a random server from range [0..3].pool.ntp.org, and the pool then will supply time from an available server. Geo-location will be handled by the pool automatically.
Not sure if the Fritzbox supports that configuration.

Recent ESPEasy builds (20221105 and later) now have the option to get the time from another ESPEasy node via the P2P network. Then 1 node should be configured to use NTP as the time source, and all other ESPEasy nodes should have that setting unchecked/empty/None, but be included in the same P2P network. Time will then be automatically synced via P2P 8-)
/Ton (PayPal.me)

S_Racing
New user
Posts: 6
Joined: 04 May 2020, 14:11

Re: Reboots due to NTP host unsynchronized

#7 Post by S_Racing » 03 Dec 2022, 19:45

Unfortunately, I do not remember the reboot reason anymore. I was focused on understanding why all ESP devices did not get the NTP data, so relatively soon I was more checking options on the Fritzbox and NTP server side. By the way - quite a strange feeling if "something" is able to make multiple devices in your house go crazy. In a first instance my thoughts where around my network was hacked.

However, all my ESP devices have a fixed IP and are blocked by filters from the Fritzbox router from accessing the internet (not sure if that bring security, but I never had a reason not to block it). So likely the ESP devices would not have a chance to find their own way to a NTP server in the internet.
Acc. to the description on the setup page, the Fritzbox works as a internal timeserver.

I just made a test and disabled the option in the Fritzbox to work as a NTP server. But the ESP devises then do NOT show "NTP: NTP host (xxx.xxx.xxx.x) unsynchronized", they seem to still get NTP data despite being officially blocked from the internet by my router. Maybe the test was not long enough (had it disabled for 30 minutes) ???

If no one else than me experienced ESP devices rebooting around 08.00 am CET at Dec. 2nd using 2.europe.pool.ntp.org as a NTP server, then my conlusion would be:
- Effect had a local root cause (not caused by a potential unaccessibility of 2.europe.pool.ntp.org) - probably issues with my network router (Fritzbox)
- The error log "NTP: NTP host (xxx.xxx.xxx.x) unsynchronized" may not be a hard indicator that the issue is related to unaccessibility of a NTP server.

User avatar
Ath
Normal user
Posts: 3416
Joined: 10 Jun 2018, 12:06
Location: NL

Re: Reboots due to NTP host unsynchronized

#8 Post by Ath » 03 Dec 2022, 20:06

Is there a chance that the Fritzbox got a firmware update during that time? (Don't expect it to, should be manually updated, never automatically, IMHO.)
/Ton (PayPal.me)

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Reboots due to NTP host unsynchronized

#9 Post by TD-er » 03 Dec 2022, 21:49

I'm not sure how the Fritzbox implementation is regarding NTP.
I always thought it maintained its own clock and then locally serves NTP requests when called for.
When it acts as a relay, it would still not directly let a local host connect to the internet. But it could timeout.
And if it has a timeout, it might be possible it does reply with an otherwise rarely seen "unsynchronized" flag being set.

It is also possible the Fritzbox may not consider itself as being synced when the last attempt was too long ago.

Like I said, this log entry for "unsynchronized" was added as I noticed it in the RFC describing NTP, but I never ever seen it happen.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 30 guests