Bumping this because it's the top forum result for M601 and this behavior still exists with octoprint and default generated gcode from prusaslicer today, so it continues to be an annoyance
For prusa printers, M601 pauses the print, and when it does this, it saves the current position and temperature, disables the hotend, parks the print head, and waits for you to continue.
When printing from SD, the UI of the printer will block when it encounters a 601, and will wait for you to press OK, before automatically continuing.
But when printing from a serial connection (e.g. octoprint) it will not do this - the UI will remain enabled, as though the print is still ongoing. However, the head park and the cooldown will still occur. The printer's UI for some reason doesn't "understand" that it is paused and cannot initiate a resume, possibly because there has not in the past been a reliable way to backfeed to the controller that a "resume" event has occurred.
But crucially, gcode prusaslicer generates by default only includes a G601 command, so there is an indefinite pause. You need to manually issue a G602 (resume) command on the terminal, which will unpark the head and reheat the hotend. Prusaslicer does not include this command in generated gcode, and octoprint is not clever enough to determine which type of pause was issued, and issue the corresponding unpause when the user resumes from the UI.
I think this is the cause of this odd, annoying behavior, and the solution would be for octoprint to explicitly issue an M602 unpause after a print interrupted by M601 is resumed by the user, regardless of whether it occurs in the gcode file octoprint is processing.
Also of note: There is a G603 command to stop the print - this would be useful for cancelling a print in the paused state, as otherwise octoprint will think the print job is over, but the pause state will persist on the printer-side, which will retain the stored head unpark coordinates and hotend temperature, causing them to potentially be restored unexpectedly during future prints, and also causing it to ignore additional pause commands completely (this is I believe the cause of the common "octoprint isn't pausing on 601, so use a color change command instead" issue)
