time_error-0x2041-clock-unsynchronized (Linux Questions. Org)

  • NTP Log

    85543 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized


    Above is a link to clock sync issue resolution. That seems to fix following NTP Sync issue:

    However not sure how you would go about editing this directly in pfsense think this would be an edit pfsense team would need to fix or Netgate

  • Netgate Administrator

    What fix exactly are you referring to there? The solution there appears to be 'wait a bit'.


  • @stephenw10
    my mistake I thought he had made some edits to NTP .confg
    It appeared to me at quick glance that he had made some changes and edits not just start/stop ntp daemon and not just wait a bit on the sync., mostly and i just noticed the last comment whatever he did fixed the sync issue. sorry, for not reading more thoroughly, just found an article that seemed to address the clock sync issue I am still having, and not that the link provided anything usual for me either. I still have sync issue. though the clock is accurately reporting time i get same time error in NTP logs
    ntpd 68677 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

  • Netgate Administrator

    Is your system clock even close to the correct time?

    Is NTP reporting the correct time?

    It's not an error I've seen before, in pfSense or anywhere.


  • @stephenw10 I think maybe I am having alot of GUI PHP issues that are not reporting accurate info or syncing back to the Dashboard GUI. Which they said could happen on upgrade, suppose it will get fixed later at some point. I had issue with PHP error like other folks.

    On a separate note, My NTP service log shows clock sync error still, I guess it is not a critical problem but I think I would like to get it fixed all the same.
    so it is working like before the upgrade.

    Back to GUI
    I did see an error in reporting correct time zone Chicago was showing EDT time zone....so
    I tried fooling around with different time zones in Gen Setup and changing those around from a EDT, CDT, MDT cities. What I found was the it would incorrectly report Chicago as EDT and Detroit as EDT, When they are both CDT zone. Then it would just hang Chicago on EDT.and would change the zone. So i moved to Phoenix time and then back and then to Denver and Back and then it finally set Chicago to CDT. So i have to believe as prior note said PHP and GUI reporting (i.e. the Dashboard) aren't syncing to well just yet. But I am a little more worried that my NTP log shows clock sync errors. Not sure why that is happening it wasn't there in 2.4.3 so guess some tweaks coming might settle things down a bit more. But thanks for asking, if you here anything or think i should check some setting let me know. As for now, the Duder abides!

  • Netgate Administrator

    I think that probably unrelated. All php errors show the time and timezone.

    The safest thing to do if you have any doubts is backup the config file, re-install 2.4.4 clean and restore the config.


  • LAYER 8 Global Moderator

    As I asked in your other ntp thread - what is your ntp status showing? As to time zone and gui - changing timezones might need a reboot to make sure all systems are using the correct timezone..

    With your errors I am with stephenw10 here - prob best to clean install..

  • @johnpoz
    Yeah John also per previous I did say the time was reporting ok. At the time that I was experiencing the PHP issue.

    I did mention NTP clock sync issue showing in my NTP log but the GUI was reporting time correctly.

    Subsequently a couple days after I experienced a crash with IDS/IPS going down stopping and restarting and few other systems going off line and restarting.

    And that after is when the GUI started reporting incorrect time for several time zones which I have fixed but will check again tonight. The main issue to me now is not the PHP error but the Clock sync issue

    So if you recommend I backup and then a fresh download of 2.44 again I will do that

    Thanks again for all the advice!

Log in to reply