The upgrade script no longer runs a Pi 2 or Pi 3 out of memory, and other fixes
A memory card with an unusual product name no longer turns off storage health monitoring, and starting the viewer no longer logs an error about a missing process file.
Fixes
- Running
bin/upgrade_containers.shyourself on a board with less than 1.5 GiB of memory, such as a Pi 2 or Pi 3, now stops the viewer and the background worker before pulling new images, and starts them again on the new ones. Pulling with the viewer running could use up memory and swap and reset the board halfway through. The screen shows no content during the pull, and the web interface stays up. Upgrades through the installer already stopped every container first. - A memory card whose product name contains a byte that isn't valid UTF-8 no longer stops storage health monitoring, which the storage card on the System Info page relies on.
- Starting the viewer no longer logs
/proc/<pid>/oom_score_adj: No such file or directory.
For contributors
- A test fails the build if a background task has a hard time limit without a soft one below it, and another fails it if a module the viewer imports pulls in celery, which the viewer image doesn't ship.
- New tests cover the soft time limit handling, the database readiness wait, the viewer's startup and respawn paths, and SQLite backup and restore.
Python, JavaScript and GitHub Actions dependencies are updated.