[BUG]: System can go to sleep, and when it does, image download/write is interrupted

[logiclrd]

What happened?

I fired up the Raspberry Pi Imager to write an image for use on a device, and the Internet connection was really slow. I left the system to do its thing and when I returned some time later, I found that it had decided it was idle and had gone to sleep. When it came out of sleep mode, the operation sat for a long time waiting for the next network packet that was never going to come and then failed with an error.

• The tool should make use of platform-specific facilities to disable automatic suspend during the execution of a DownloadThread.
• If the system does go to sleep, a more robust retry/error-handling strategy is needed. For instance, instead of simpy aborting, the user could be prompted about whether to try to resume the process if automated retry has failed too many times. The time it takes for the user to react may give Wi-Fi enough time to reconnect.

I found this cross-platform C++ Gist showing how to inhibit suspend on Windows, OS X and Gnome on Linux:

https://gist.github.com/Vineg/eca223fbf478a3c806444a13e538a9fc

The KDE method is probably similar, though in my surface-level-only search I uncovered only a command-line tool to do it: kde-inhibit

Version

1.9.6 (Default)

What host operating system were you using?

Windows

Host OS Version

Windows 10

Selected OS

Raspberry Pi OS 64-bit

Which Raspberry Pi Device are you using?

Raspberry Pi Zero 2 W

What kind of storage device are you using?

microSD Card in an internal reader

OS Customisation

• [x] Yes, I was using OS Customisation when the bug occurred.

Relevant log output

[yanxke]

Should just resume if the network is interrupted. Switching Wifi networks will also cause this. Modern software should be reliable against these simple failures.

[logiclrd]

It didn't resume, but also if it's a time-consuming process, I want to be able to walk away and come back some time later and not find that the computer went to sleep after 5 minutes and nothing further has happened.

[logiclrd]

I suspect it does have a retry mechanism, but when coming out of sleep mode, code starts running well before the network has reinitialized, so it would quickly exhaust retries with immediate failures due to the network not yet being established. That is what I'm referring to when I say I think it needs a more robust strategy.

[tdewey-rpi]

Merged for 2.0. Closing.