<@U0AEFTKRV> we saw the exact same problem with a ...
# lucee
m
@dswitzer we saw the exact same problem with a client of us, in that case the the server “pool.ntp.org” was enabled and it seem that that server did report an invalid time yesterday, what Lucee did interpret as 0 what is equal to 1900/1/1. If you have enabled the timeserver best disable it, that feature is not very useful anymore with todays server. we may will remove that from future versions of Lucee.
⭐ 1
d
Thanks. We just now saw the issue again.
m
do you run commandbox?
d
No, running via Tomcat
Where is this setting?
m
this shows you if the setting is enabled
<cfscript> pc=getPageContext(); dump(“getTimeServerOffset: “&pc.getConfig().getTimeServerOffset()); dump(“getUseTimeServer: “&pc.getConfig().getUseTimeServer()); dump(“getTimeServer: “&pc.getConfig().getTimeServer()); </cfscript>
d
Found it Regional > Settings
m
in the Lucee admin
d
I bet that's it
You're a life saver!
That's caused me all sorts of issues in the past 24 hours!
Just to confirm, if I uncheck the "User time server" option, that's enough to prevent it from happening, right?
m
yes i hope so, let me know if it does the trick
d
Thanks. Should I clear the "pool.ntp.org" just to be safe?
m
sure, no need for that
d
It doesn't appear you can clear it. When I blank the value out, it returns the default value
Given that all the OS time stamps never saw an issue and it was just now() within Lucee returning the wrong dates, I'm really confident that this was the root cause
👍 1
@micha Do you by chance now how frequently Lucee was checking the NTP server?
m
i think it does it every hour
m
I had the same issue. I just changed the setting on our servers, so hopefully that takes care of it.
m
@Matt Dyer let me know if it did the trick
s
Just as a cautionary tale: we use managed (virtual) servers in a big datacenter. They are configured to use time servers in the datacenter. One of the datacenter's time servers failed and it caused just two of our servers to drift, far enough to cause token invalidations between servers, lost sessions etc. We reconfigured all of our servers to use the same set of public time servers to fix the problem. The datacenter folks did fix the errant time server but it took 'em a week of back and forth before they believed us and isolated the problem...