OctoPrint web interface freezes, SSH terminals freeze, printer is happily printing away


#1

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!


#2

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.


#3

@foosel, I think you are right. I can't ping it either. Weird that it works until I start printing.

(There's no room next to the printer for a monitor, keyboard, mouse... I guess an ethernet cable strung across the floor is the next step).


#4

You wouldn't happen to see an undervoltage warning in OctoPrint (if you are on 1.3.10 that is)?


#5

@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?

OctoPrint.zip (1.3 MB)


#6

I disabled Discovery and rebooted in Safe Mode. Same symptoms. Network shuts down, printer keeps printing.

Any hints on where to look for WiFi error messages?


#7

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.


#8

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.


#9

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.


#10

I rebooted my WiFi access point and everything appears to be back to normal.


#11

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.