Closed zeplintwo closed 4 months ago
Staubgeborener
commented
4 months ago [...] the DNS to GitHub, even when not updating this script, [...] trigger 'Timer too close' errors in Klipper.
tbh i don't see this as a klipper-backup issue. The "timer to close" klipper error can (for example!) be triggered by weak hardware. Your raspberry (or whatever you use) may have been knocked out by the storm.
zeplintwo
commented
4 months ago Again, this is not a bug with the Klipper-backup. It works as intended when I have proper routing.
I understand how my Raspberry Pi (rPi) can cause this issue. However, before the outage, the printer and all its "weak hardware" worked without triggering the problem, so I know it was not the rPi. Additionally, a family member caused a DNS storm on the network by connecting to both the main router and the cellular router at the same time. This compounded the low availability of DNS routing.
This is a notice that DNS resolution from Klipper through Moonraker's update components can cause the "Timer To Close" error to trigger. This issue coincides with Klipper-Backup because I was using all three methods of file watch, on-boot, and 8-hour cron to trigger the backup. Once the backup files were uninstalled, the "Timer To Close" issues stopped. But, based on your code, this should not be the origin of the issues. Hence the notice that slow DNS resolution can cause the "Timer To Close" error.
This is the third day I have had this ongoing issue. It took me a day of testing all the other parts of the printer to rule them out as the cause. With the degraded network, I had believed it was bad DNS in the router even when the records were flushed. I stumbled across the DNS storm when one of the family members told me they were still directly connected to the "cell router" instead of the main network. I have not yet completed testing without the "user-caused DNS storm loop" to determine if that was the primary cause.
Staubgeborener
commented
4 months ago As
This is not directly a bug.
and
this is not a bug with the Klipper-backup. It works as intended when I have proper routing.
this is more or less some sort of information for users with similar issues and nothing which we can obviusly fix.
So i will convert this issue to a discussion for anyone else who wants to talk about that.
Code of Conduct
codemore readable which helps to fix the problemWhat happened
When using the script from Staubgeborener/klipper-backup to keep updated backups, the script can cause 'Timer too close' errors in conjunction with Happy-Hare and ERCF.
I experienced a major storm in my area, which left us without our primary ISP and its DNS routers. While running through 'personal hotspots'/cellphone ISP, the DNS to GitHub, even when not updating this script, would cause the Happy-Hare to trigger 'Timer too close' errors in Klipper.
What did you expect to happen
Normal operation without overrunning timeouts.
How to reproduce
Low avalibilty DNS routing
Additional information
Info on Why 'Timer Too Close' Can Happen - Public Service Bulletin This is not directly a bug.
When using the script from Staubgeborener/klipper-backup to keep updated backups, the script can cause 'Timer too close' errors.
I experienced a major storm in my area, which left us without our primary ISP and its DNS routers. While running through 'personal hotspots'/cellphone ISP, the DNS to GitHub, even when not updating this script, would cause the Happy-Hare to trigger 'Timer too close' errors in Klipper.
Errata to Correct from 'FAQ':
Version Information:
Removed:
The OS was updated to the current apt packages before the issue, but no specific versioning is available.
Public Service Bulletin This is more of a public service bulletin indicating that this issue could happen in rare cases. It is not a bug that needs to be addressed by the Happy-Hare team. I do not think this is an issue with Klipper-backup directly. More and timer and DNS timeout bug that cause and error to be generated by klipper.