My Raspberry Pi 4 crashed with about an hour left of a 24-hour print. I'm trying to figure out the last layer that was printed so that I can (hopefully) modify the gcode to restart at the correct layer. I've looked in ~/.octoprint/logs but don't see anything in that directory with the layer information.
Am I looking in the wrong location? Am I out of luck?
TIA
I guess the hard part is to home your printer with an object on the bed.
The nozzle is right where it was when it failed. I think I can get it to home safely by using the Octoprint stepper controls. But that doesn't help me determine what the starting height should be or where in the gcode file to start from.
You could measure the height and try it that way.
So you're certain that Octoprint doesn't maintain a log of the executed gcode commands? That seems like a pretty basic part of logging.
Not if you didn't enable the serial logging.
The last few gcode commands are only logged in the octoprint.log if for example the printer reports an error.
When your pi crashes octoprint has obviously no time to log those last commands.
I've been a sw engineer for 26 years (Microsoft, Intel, and Apple). I see absolutely no reason why each command couldn't be logged as it is sent to the printer. For example, if a PC crashes while Visual Studio is compiling a large project I know where to start building from after the crash.
I'm new to Octoprint so I guess I need to enable serial logging to obtain this behavior?
Enable serial.log if you wish to retain a copy of every command (and response). Note that this is not divided by print job but is the stream of all commands. When a new version of the file is created, old versions are renamed and kept. You should clean up the ~/.octoprint/logs directory either from the command line or from the web interface.
Note that enabling the serial log could cause performance problems. Because of this potential for problems the default is disabled.
Even with enabled serial.log you don't get the exact point in the gcode for restart. The last blocks of gcode are only in the buffer-cache and are lost without a clean shutdown. That said, my serial.log is always on and has enabled me to resume a 45 hour print-job after power-loss at hour 37 
.
Thank you jandar - that is exactly what I was looking for. I'm surprised there isn't a plugin that can help in this exact type of situation.
I guess I'm screwed given that I didn't have serial logging enabled. Lesson learned I guess. 
Thanks again for your help!
If you have an LCD, it should have X, Y, and Z positions on it. May not be to the precision in the GCode file, but close. I have used these coordinates along with calipers and a GCode viewer to figure out which layer is most likely the last one and then edited the GCode file to start printing from that point.
If you are lucky, the end result will only show a minor blemish where you restarted. My success rate is probably under 30%.
You need to do this fairly close to the time of the failure because idle timers in the firmware may trigger and the printer will assume that the position is lost (X, Y, and/or Z will be flashing in the LCD).
Thank you very much - that is great information. And you were right... the X, Y, Z coords were lost.
Given the frustration associated with these types of failed prints I wonder why it hasn't been tackled by a plugin. I'm not sure why it would be difficult to track commands and then restart appropriately in the face of a crash. I've read that some printers' firmware may have "re-start after power failure" functionality.
Power failure recovery is a special case because the loss of power can be detected while some (capacitive) reserve is available to capture the necessary restart parameters. Crashes just happen with no warning.
Even if the necessary restart parameters are kept up-to-date in non-volitile memory, Murphy says that sooner or later, a crash will involve wiping out that memory.