Closed vgroenewold closed 3 years ago
This sounds like a Kernel or driver issue. Even at 100% load Moonraker shouldn't be able to freeze ssh on a multicore system.
If you can reproduce this, disconnect the printer, then grab /tmp/moonraker.log
(give it 30 seconds or so) it might provide some insight. When Klippy enters the shutdown state Moonraker dumps its own process usage stats to the log.
Thanks, I'll try to recreate it and see if I can get a relevant section from the log.
Mm, nothing really special, I do see a wait command: 2021-05-05 19:08:04,006 [moonraker.py:wait()] - Request 'gcode/script' pending: 60.00 seconds
That was about the time it was not responding this time. I'll add more logs to this reply when I investigate further.
Little further up I also see this one, with a failure to connect and two wait commands;
2021-05-05 18:49:50,004 [websockets.py:add_websocket()] - New Websocket Added: 1753101072
2021-05-05 18:50:00,798 [file_manager.py:get_file_list()] - Updating File List
I'll need the full log to be able to help diagnose any potential issues. Thanks.
Ok, sorry for that, let me finish a print and then I'll try to force the error and send the entire log. Thanks for the help!
Sorry for the long file, but this is the one from today. I at least experience 2 "disconnects" just during printing. I'm also wondering, even though my Pi has good wifi, if it may be a connection problem there.
Thanks, however moonraker.log
is the one I require. I might be able to glean some info from Klippy.log, but if there is a specific issue with moonraker it will be in there.
Oh wow, must have been a long day today. Let me try that again tomorrow, sorry about that.
Alright, here is the new one. During the print I saw Klippy not updating for a big period towards the end; moonraker.log
Looks like the websocket connection was dropped. Since it occured in the middle of a status update some exceptions are logged while it tries to write to a closed socket, which is to be expected.
My guess is that its some kind of networking issue.
Ok, interesting. My pi is connected to wifi which is strong here, but maybe there's an issue there. I might try to hook it up via cable to check. Thanks!
moonraker How to execute gcode wait to finish blocking call?
This seems like a buffer issue, but I often (few times a day) have the problem that I execute something on the Fluidd UI (like bed leveling, or adjusting Z while printing, or... seems rather random) and the UI becomes unresponsive. I can still click around, but commands are not being send to the Pi nor received, prints always continue so my guess is that the Pi becomes too busy. But how can I diagnose that or even solve it?
edit: I did some extra diagnosis with Htop running at the same time in a shell and that simply freezes as well for instance when the print starts for heating up and leveling. No comms whatsoever during that time, is it moonraker blocking that maybe? Resources looked totally fine. The only way to get responsiveness back immediately it to disconnect the Pi from the printer.
Thanks