New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Occasionally getting NTPExceptions - uncaught #256
Comments
Fixes #256. When the request times out, this exception is thrown. For now, just default to the local time. The timeout parameter in the request() function of the NTPClient can also be adjusted. This can be extended for (hopefully) better reliability of the NTP request.
Thanks for filing this issue. I fixed this in the latest commit of the While falling over to local time is what we want in these scenarios, I still want to see if we can make the NTP requests more reliable (another reason why I don't want to catch a very general exception, as I want to see what exceptions actually could come from this request so it can be looked into and made more reliable, meaning reverting to local time is used as little as possible). This is where the exception is being raised, which is from a socket timeout. Before merging the latest commit that catches this error, would you be able to set a longer timeout and see if you still get the exception a lot? If you aren't, I can adjust the timeout in the script to make NTP requests more reliable. The change to be done is below: diff --git a/lib/utils.py b/lib/utils.py
index 77cdb61..9a17a5c 100644
--- a/lib/utils.py
+++ b/lib/utils.py
@@ -72,8 +72,8 @@ def get_current_time() -> datetime:
c = ntplib.NTPClient()
try:
- response = c.request(NTP_SERVER, version=3)
+ response = c.request(NTP_SERVER, version=3, timeout=10)
except socket.gaierror:
logger.debug("Error requesting time from NTP server. Using local time")
return datetime.utcnow() 10 seconds seems a bit long, but if the requests do succeed after a longer time, then I see that being a good thing especially because this function is never called when timing is absolutely critical. |
Yeah, let me change the timeout and see how often it happens (if at all). I am surprised that the default (5 second) timeout is still not long enough sometimes. Makes sense about not catching a more general exception. |
Hey @aaron-pham, have you still been reaching the NTP exceptions with a longer timeout? |
I have not seen the timeouts ever since changing it to 10 seconds. Think we can close this issue now! |
Awesome, I will make the change in the script too. Thanks for following up @aaron-pham! |
A follow-up to #256. Setting a longer timeout allows for more time for NTP requests to go through, making the requests more reliable (the goal is to use the system's time as little as possible).
A follow-up to #256. Setting a longer timeout allows for more time for NTP requests to go through, making the requests more reliable (the goal is to use the system's time as little as possible).
Lol of course after I thought it's working good & complete, I have some issues haha. I'm heading to work so didn't have a chance to debug it at all, but here's the stack trace:
Let me know if you want me to open a new issue. Also, I probably need to investigate why NTP is timing out so much on my PC. It seems abnormal. |
datetime.now(timezone.utc) includes tzinfo whereas datetime.utcnow() (which is now deprecated so it was changed to the former) does not include tzinfo. This is a simple fix to just remove the tzinfo as there is no timezone info for a flight's departure time (when comparing a time with and without tzinfo, an exception would be thrown). See #256 (comment) for a traceback of the issue before this fix.
Thanks @aaron-pham. When I replaced |
Version
7.4
Browser Version
124.0.6367.118
Description
I'm not quite sure why, but locally on my machine I occasionally get a NTPException. I'm not sure what exactly happens (or why), but I notice that during the NTP call we're only catching a socket exception for falling back to system time. So I think we need to catch a more general exception.
To Reproduce
Expected Behavior
If an exception occurs, fall back to system time.
Relevant logs and program output
Additional context
No response
The text was updated successfully, but these errors were encountered: