OctoPi becomes unresponsive after left unattended for some time

Get Help
1

I have noticed that when left unattended my RPi with OctoPi goes completely offline and becomes unresponsive. The RPi lights are on, the USB Wi-Fi is not blinking, but I can't ping or connect to the host neither via SSH nor with HTTP. The only thing that helps is pulling the micro USB power out and rebooting the RPi. It looks almost like the RPi is sleeping, but since there is no keyboard or monitor attached to it, it is hard to say.
I poked around the OctoPi settings and RPi settings but did not find anything that configures sleep cycle / timeout etc.

My OctoPi/Print version: 1.3.8

Any ideas what might be going on? Anyone else experiencing the same issue?

2

Is it a Raspberry Pi 3B+ (emphasis on the plus)?

Google: Raspberry Pi 3B+ freezing

3

No, this is an old RPi 2 B+

It used to work just fine with the same hardware configuration (just really a wifi usb adapter) for over a year and only recently I started noticing this behavior

4

I will say that I've spoken before about what seems to be some radical changes to the networking in Raspbian Stretch which I don't necessarily love.

Some background:

  • The computer-on-a-chip at the heart of a Raspberry Pi is made by Broadcom
  • The UNIX network drivers for the Ethernet adapter are rock solid but the sleep management for the wi-fi side of things has never been good for the Broadcom chipset
  • This goes beyond Raspbian to any Linux/Debian/UNIX install with wi-fi, like on a laptop computer

The strategy is mostly to not allow the power-saving features for wi-fi, to not attempt to go into a sleep mode (just shutdown and startup again).

So maybe your assumption is correct, the Pi has gone into an idle/sleep mode and you don't have a keyboard to wake it up. Researching this, some suggest that the Pi does not have a sleep mode.

Now that I think about it, you just mentioned that your wi-fi is a USB dongle. Its power management would be from a different driver stack and it could be doing the power-saving thing.

This thread would have been pertinent back with Raspbian Wheezy and it's typically what would have been done earlier to disable power management on a network adapter. Now that we're using wpa_supplicant, a statement like that would have to go in a different file.

5

Thanks, let me try disabling the sleep mode and see if it helps

6

Yeah..see if usb autosuspend mode is turned on

7

Does it continue to print in this state? Mine will constantly drop off the network, I have no idea why but it only affects single board computers, all of my raspberry pi's, built in wifi, usb dongles, and a pcduino running armbian. If they drop off the network, they won't reconnect until you reset the wireless adaptor, or in the case of the pcduino you have to unload the driver and reload it. I have no clue why they're so unreliable when every other device on my network will just stay connected.

In any case, if the octopi server continues to print, but is unresponsive, try running a small utility in the background that checks the wifi every so often, this is the one I run https://github.com/wxlcat/NetReconnector albeit slightly modified to not only pull down the interface, but also unload the drivers https://github.com/ntoff/NetReconnector

Note: Disabling any sort of wifi sleep mode or suspend nonsense does not fix my issue, I'm assuming it's because the wifi signal is so bad in the print room as my tablet also drops out down there but usually it reconnects itself fine.

8

In my case the pronting and responsiveness are not affected at all. I think it is a sleep or USB sleep problem

9

I'm seeming to have a similar problem. Rpi3 using onboard WiFi. After a print (and probably several hours later), I can't get the buttons on the GUI to make changes (preheat, set temperature, load file, upload file, print, ...). They all seem to do nothing or give me weird error messages.

But the 'terminal' does continue to output temperature logging. So the wifi is still working, and hasn't gone to sleep.

I end up power cycling the rpi3, and then everything is happy again. I just really dislike having to wait 2 minutes to start the next print.

10

Thanks heaps, I have been looking for a solution to the same problem on my CR10S Pro V2.