Prevent raspberry pi 5 from going to power-saving or sleep mode

[abbjetmus]

After the screen has been on for a few hours it goes in a power-saving mode or sleep mode and turns black. I'm using a Raspberry Pi 5 with Raspberry Pi OS with desktop Debian 64bit.

Do you have any suggestions how to prevent this?

[Pacobg]

I have the same problem. I'm using a Raspberry Pi 4 2GB RAM with Raspberry Pi OS with a desktop 32bit. After 6-7 hours chromium exits to the desktop. Any idea? 10X

[debloper]

For me, after ~8hrs the browser randomly crashes/quits, but the system stays ON. It doesn't go into sleep mode & screen stays on as well.

I have tried looking here and there - to understand why is this uncanny incident so deterministic but found no good answer that made sense.

Keeping it open for further investigation. Needs to be patched ASAP.

[Pacobg]

Hi, i've found same problem here, and may be some solutions. https://www.reddit.com/r/raspberry_pi/comments/1fhrfba/kiosk_mode_stops_after_roughly_6_or_7_hours/

[andiohn]

Seems like it could be a memory leak? Large website, poor feature?

[andiohn]

Hey thank link also has a keepalive in it. We could probably adapt that here.

[andiohn]

There's this to maybe help. Here's the relevant parts; (https://diode.io/blog/running-forever-with-the-raspberry-pi-hardware-watchdog)

Enter Watchdog But the Pis are very resourceful tools. And one of their underdocumented features is a builtin hardware watchdog. This little hardware service will once enabled watch the system activity and automatically power cycle the Raspberry Pi once it gets stuck.

So if you’re running your Raspberry Pi as a remote sensor reachable remotely from any place in the world with Diode network, then we recommend to enable this hardware watchdog for your devices as well.

It’s done in few steps directly on a terminal on your Pi:

1) Enable the hardware watchdog on your Pi and reboot

sudo su echo 'dtparam=watchdog=on' >> /boot/config.txt reboot After this reboot the hardware device will be visible to the system. The next steps install the software side of this to communicate with the watchdog.

2) Install the watchdog system service

sudo apt-get update sudo apt-get install watchdog 3) Configure the watchdog service

sudo su echo 'watchdog-device = /dev/watchdog' >> /etc/watchdog.conf echo 'watchdog-timeout = 15' >> /etc/watchdog.conf echo 'max-load-1 = 24' >> /etc/watchdog.conf 4) Enable the service

sudo systemctl enable watchdog sudo systemctl start watchdog sudo systemctl status watchdog If everything worked then you should after the last command output similar to this:

Watchdog service running

Now next time your Raspberry Pi freezes, the hardware watchdog will restart it automatically after 15 seconds.

If you want to test this you can try running a fork bomb on your shell:

sudo bash -c ':(){ :|:& };:' WARNING Running this code will render your Raspberry Pi inaccessible until it’s reset by the watchdog. /WARNING

If you got any troubles with your Pi or running Diode on the Pi feel free to reach out to us on Telegram and ask questions directly there.

And if you want to learn more about Diode be sure to check out the Diode FAQs.

Update: July 21st In some cases our Raspberry Pi Zero W would crash it’s WiFi driver but not completely go down. This wouldn’t trigger the watchdog, because the device is still running - just not communicating anymore… To handle this case we added one more line to the watchdog.conf configuration file. Like this:

sudo su echo 'interface = wlan0' >> /etc/watchdog.conf With this additional configuration line, the watchdog will also power cycle the Raspberry Pi when the WiFi interface wlan0 gets into trouble.

[andiohn]

More info:

https://fleetstack.io/blog/how-to-set-up-watchdog-timer-raspberry-pi

[debloper]

@andiohn fantastic research!

Regardless of whether hardware lockdown is the main reason for the crash, this is a good fix to add to PiOSK anyway (improves operation reliability & uptime, without any downside).

The reason I'm not entirely sure if this is the reason, cause the symptoms don't match. I am able to SSH into & otherwise use the device fine. I can even run the script to start the KiOSK mode manually as well. Had it been the issue described by the article, all these shouldn't be possible. Maybe I'm having a different issue - cause I am yet to face a hardware lock down, as it's described in the blog.

Out of curiosity (as you've already done the main heavy-lifting) would you be willing to submit a patch for this? The steps will just go into the setup script. And don't worry, I'll help you along the way.