Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
MangoES Timestamp Does Not Match Local Time
-
Hi there,
I'm using a MangoES device with core v3.7.7.
I've set the time zone of the MangoES to America/Toronto (through the UI and confirmed it is correctly set in the FTP directory in /etc/timezone). I restarted the database, however it appears that there is a ~24 minute delay between the Mango server time and local time. It affects all Modbus point logging and script executions, which is not ideal. I confirmed using javascript (new Date()) that the time is in fact delayed by 24 mins.
Are there some steps I could follow to ensure the server time lines up with the time zone I've set?
It could also be an issue with the overarching network - not savvy enough to know what influences the Mango time. Any help would be appreciated.
See photo (I refreshed the datapt History before taking the sc)
-
@ottawa_admin Did you check what the system time is via the terminal? I'm not sure what your screenshot is showing. When your Data Points update the time that shows is 24 minutes behind the current time? I'm not aware of any way that could happen other than your system time being off.
-
@joelhaggar the previous screenshot was showing that the network time on the bottom right was 4:16pm (matched local time). And that the point logging history was showing a most recent update time of ~3:53pm with most recent point logged at ~3:52pm.
When a new data point is logged, its timestamp matches the system time. However the issue is that system time doesn't match the time zone time exactly - it's delayed by ~24 mins.
I confirmed through command line in PuTTY that the Mango's system time is behind by ~24 mins (10:12am) compared to the local time of 10:36am.
See photo:
-
@ottawa_admin Ok, thanks for the clarification. That would point me to it not syncing with a time server correctly. Does the device have internet connectivity? It should sync to a time server using NTP. Have you made any changes to the NTP settings. Maybe double-check the NTP settings and force a resync and see if that resolves it.
-
Definitely seems like classic clock drift. If the device has internet access you'll probably want to try and ping whatever NTP server is configured in the device. If it can't reach it then you'll need to change it.
-
@joelhaggar Thank you for the information. I was able to look through the NTP and timesyncd config files, and things looked alright. However I discovered I was having problems with internet connectivity and DNS resolving on the device in question. I discovered that it didn't have a default IP routing path. Considering we didn't need an outwards internet connection for our projects, makes sense that I didn't pick up on it.
I looked at another MangoES device on the same network and discovered it had an internet connection, so my issue was isolated. I added a default IP route using "sudo ip route add default via XX.XX.XX.XX dev eth0", and borrowed the gateway info from a functioning device. I then overwrote the DNS resolve file found at "/etc/resolv.conf" with "nameserver 8.8.8.8".
Not sure how things go out of hand in the first place, but I used "sudo date +%T -s "hh:mm:ss" to bring the unsynced time within a few seconds of the local time. I then forced the NTP to restart using "sudo service ntp restart", checked the ntp status using "sudo service ntp status", and then it looked like my ntp hosts were being resolved correctly and the time had resynced.
Appreciate the help Joel!
-
@ottawa_admin thanks for the feedback and for letting us know how you resolved it!
-
@ottawa_admin I may be wrong but I think that resolv.conf gets overwritten on reboot.
-
@psysak Hmm, that would surprise me if it was overwritten on reboot but I have seen this a few times where the DNS isn't updated correctly and has to be manually edited. Let us know if that continues to be an issue.
-
@joelhaggar I ran "sudo service networking restart" and resolv.conf doesn't appear to have changed. I also ran "sudo service mango restart" and still no change. Although please advise if I should do another test.
Thanks for the tip Mr. Sysak! :) Definitely would have been a concern if it was being overwritten and the drift continued.
-
@ottawa_admin on many linux distros resolv.conf tends to have a blurb similar to this "# This file is managed by man:systemd-resolved(8). Do not edit." I can't remember how the ES works but that's something that will burn you if it's not configured correctly.
Restarting the mango service itself would not affect it since this is a system level function. What you'd need to do is restart the whole ES so that Linux reboots and then have a look to see if your entries are still there.
