You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I uploaded a printer config file with an error in it. Klipper crashed and the connection to Klippy was closed. But then I reverted the change by uploading a known-good config file via Fluidd. Moonraker didn't re-establlish a connection to Kilppy after the correct file was uploaded. So now Fluidd is reporting (correctly) that Klippy is disconnected.
Could there be a race where if the server happens to be down (because I broke it by the bad config file) when the Kilppy connection is closed, then Moonraker won't restart the connection later after Klippper is healthy? If yes, then would this explain the behavior we're seeing?
Here's the Moonraker logs from the first upload of the bad file:
Upload a config file that causes startup to fail (don't use any backup config)
Revert to a known-good version of that file
Expected: Klippy is reconnected
Actual: Klippy is still disconnected.
Additional information
If this is expected behavior, then what's the recommended recovery step to force the Klippy connection to be re-established? I'd prefer to avoid having to reboot the printer if we can do something that gets the printer back to functional quicker.
The text was updated successfully, but these errors were encountered:
justingrant
changed the title
Moonraker won't reconnect (due to race while server is restarting?)
Moonraker won't reconnect after recovering from a Klipper crash
Nov 12, 2024
Please include full logs, snippets don't provide all the information required diagnose a potential issue.
Moonraker didn't re-establlish a connection to Kilppy after the correct file was uploaded.
Merely uploading a new configuration file wouldn't be enough to bring Klippy back up in the event of a crash. You would need to restart the Klipper service.
Could there be a race where if the server happens to be down (because I broke it by the bad config file) when the Kilppy connection is closed, then Moonraker won't restart the connection later after Klippper is healthy?
No. The server does not depend on Klippy. This line of code prevents Moonraker from attempting to reconnect after Moonraker is commanded to exit.
What happened
I uploaded a printer config file with an error in it. Klipper crashed and the connection to Klippy was closed. But then I reverted the change by uploading a known-good config file via Fluidd. Moonraker didn't re-establlish a connection to Kilppy after the correct file was uploaded. So now Fluidd is reporting (correctly) that Klippy is disconnected.
Inside Moonraker's KlippyConnection._on_connection_closed, I saw this:
moonraker/moonraker/components/klippy_connection.py
Lines 780 to 784 in 4e00a07
Could there be a race where if the server happens to be down (because I broke it by the bad config file) when the Kilppy connection is closed, then Moonraker won't restart the connection later after Klippper is healthy? If yes, then would this explain the behavior we're seeing?
Here's the Moonraker logs from the first upload of the bad file:
And here's the log lines from when the fixed file was uploaded:
Client
Fluidd
Browser
Chrome
How to reproduce
Expected: Klippy is reconnected
Actual: Klippy is still disconnected.
Additional information
If this is expected behavior, then what's the recommended recovery step to force the Klippy connection to be re-established? I'd prefer to avoid having to reboot the printer if we can do something that gets the printer back to functional quicker.
The text was updated successfully, but these errors were encountered: