What is the problem?
OctoPrint web interface freezes, SSH terminals freeze, printer is happily printing away
What did you already try to solve it?
Nothing yet, printer is happily printing atm.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
OctoPi 0.14, OctoPrint 1.3.10, LulzBot TAZ 6, Marlin 1.1.9.28
I can't get logs or terminal tab output because the web interface is frozen and SSH sessions are not working (old ones or new ones). I'll reboot and capture these after the print finishes, try safe mode, and all the usual stuff.
In the mean time, if anyone has any ideas, I'm all ears!
Sounds like your Pi has fallen off the LAN. If SSH doesn't even work anymore (what about ping?) then that's a surefire way to tell it's not OctoPrint specific but affects the whole system. I'd investigate in that direction.
@foosel, Yes, I am on 1.3.10 and no, I don't see an undervoltage warning in the octoprint.log (which is attached along with the serial.log).
There are some messages I don't remember seeing from the Discovery plugin (which I think is written by you and is a bundled plugin). Any comments on these?
Whoa... something on your network at 192.168.0.141 and 192.168.0.192 is spamming this poor machine with UPNP discovery requests. That's unusual. Any idea what devices are behind those IP addresses? And considering that for some reason it can't figure out how to reply to them (which will happen if it isn't able to successfully send an UDP datagram to that address from any of its own) - on what network is that instance?
What's interesting is that each of those log floods also coincides with OctoPrint detecting a connectivity change from online to offline. Considering that it still receives UDP messages though that it tries to reply to, I wonder if it is only semi connected? Really odd...
If I were you, I'd first try to figure out what those two devices are (just in case they could be related). And then - ethernet cable and monitoring the wifi reception.
192.168.0.141 is a Windows 10 Professional system that runs my backups and my media center. 192.168.0.192 is my main desktop, also Windows 10 Professional, where I run my slicer(s) and monitor OctoPrint. Both of these machines have been on my network since I first got my printer and OctoPrint. Over a year ago and many, many versions of OctoPrint.
192.168.0.141 does have iTunes so there is Apple software loaded (but not iCloud) and there is an iPad and an iPhone on the network.
I have installed an ethernet wire and OctoPrint and SSH are again happy (as is the printer, happy to be printing again). More research into WiFi will commence post haste.
According to "ifconfig" and "iwconfig", wlan0 is up but does not have an IP address on my network. An "ifdown wlan0" and "ifup wlan0" and its back on my network again.
I'll reboot my access point and see if that helps any.
I will note that my own instance sometimes lately acts as if it's not responding to its name (Bonjour problems?) so I note that anything that tries to ask-by-hostname just grinds away: ssh, scp, browser, vnc. I've dedicated IP addresses in my Netgear router so I know it's not DHCP lease.
This seems to be a new thing, perhaps two months old at most.
macOS for workstation and there's no Windows anywhere on my network.
Netgear CN3000 and (Netgear) Orbi wi-fi repeaters
v1.3.10, of course
Raspberry Pi 3B and a Robo C2 printer
Using the IP address seems to be a lot happier in these cases.
Note that this is one of those lonnnnnnng-troubleshooting things where I'm watching it to see if it reoccurs. The last thing I did was to modify my /etc/haproxy/haproxy.cfg in two places:
global
tune.ssl.default-dh-param 2048
...
frontend public
bind *:80
bind 0.0.0.0:443 ssl crt /etc/ssl/snakeoil.pem
In other words, I removed the IPv6 stuff out of there (and I addressed a problem that was showing up in one of the logs which referred to tune.ssl...)
I'm crossing my fingers but I haven't seen the problem since doing this, for what it's worth. No guarantees, though.
This is most likely due to the DHCP lease expiring. OctoPi hasn't crashed, its just that the WiFi doesn't have a valid IP address. The RPi is supposed to renew the lease when it expires but for some reason, it does not.
One solution is to assign a static IP address to the RPi.