• Recent
    • Tags
    • Popular
    • Register
    • Login

    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.

    Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website Mango 5 Documentation Website

    MangoES Timestamp Does Not Match Local Time

    User help
    3
    11
    1.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • O
      ottawa_admin
      last edited by

      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) Mango - Timestamp Discrepancy.PNG

      JoelHaggarJ 1 Reply Last reply Reply Quote 0
      • JoelHaggarJ
        JoelHaggar @ottawa_admin
        last edited by

        @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.

        O 1 Reply Last reply Reply Quote 0
        • O
          ottawa_admin @JoelHaggar
          last edited by

          @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: Mango - Timestamp Discrepancy -Terminal.PNG

          JoelHaggarJ 1 Reply Last reply Reply Quote 0
          • JoelHaggarJ
            JoelHaggar @ottawa_admin
            last edited by

            @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.

            O 1 Reply Last reply Reply Quote 0
            • P
              psysak
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • O
                ottawa_admin @JoelHaggar
                last edited by

                @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!

                JoelHaggarJ P 2 Replies Last reply Reply Quote 1
                • JoelHaggarJ
                  JoelHaggar @ottawa_admin
                  last edited by

                  @ottawa_admin thanks for the feedback and for letting us know how you resolved it!

                  1 Reply Last reply Reply Quote 0
                  • P
                    psysak @ottawa_admin
                    last edited by

                    @ottawa_admin I may be wrong but I think that resolv.conf gets overwritten on reboot.

                    JoelHaggarJ 1 Reply Last reply Reply Quote 0
                    • JoelHaggarJ
                      JoelHaggar @psysak
                      last edited by

                      @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.

                      O 1 Reply Last reply Reply Quote 0
                      • O
                        ottawa_admin @JoelHaggar
                        last edited by

                        @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.

                        P 1 Reply Last reply Reply Quote 0
                        • P
                          psysak @ottawa_admin
                          last edited by psysak

                          @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.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post