Upgrade/repair: a down database must never block the pipeline.
Some checks are pending
CodeQL / Analyze (push) Waiting to run
Controller Tests / controller-tests (push) Waiting to run
Jest Tests / jest-tests (push) Waiting to run

scripts/upgrade.sh ran `main.py db upgrade` under set -e before
repair.sh, so a broken Postgres bricked the very upgrade carrying the
fix for it (seen live: the bootstrap bind-mount fix could not be
delivered because the binds had already killed the cluster).  repair.sh
had the same problem with initialize_api_db.sh and the superuser psql.

Warn and continue instead: the migration is retried by
initialize_api_db.sh during repair, and if the database is still down
afterwards the API reports it loudly while the system-level work
(configs, services, bootstrap refresh) still completes.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Roland 2026-07-05 15:40:47 -06:00
parent 9d778d25a5
commit 756c063d15
No known key found for this signature in database
GPG key ID: 1BA620CE6C9A4680
2 changed files with 11 additions and 5 deletions

View file

@ -143,10 +143,13 @@ chmod 0440 /etc/sudoers.d/90-wrolpi
# Verify this new file is valid.
visudo -c -f /etc/sudoers.d/90-wrolpi
# Configure Postgresql. Do this after the API is stopped.
/opt/wrolpi/scripts/initialize_api_db.sh
# Configure Postgresql. Do this after the API is stopped. Never fatal: a
# repair/upgrade must complete its system-level work even when the database
# is down (e.g. it is the reboot after this repair that revives Postgres).
/opt/wrolpi/scripts/initialize_api_db.sh || \
echo "WARNING: could not initialize the database; the API will report if it stays down."
# wrolpi user is superuser so they can import maps.
sudo -iu postgres psql -c "alter user wrolpi with superuser"
sudo -iu postgres psql -c "alter user wrolpi with superuser" || :
# Create the media directory. This should be mounted by the maintainer.
[ -d /media/wrolpi ] || mkdir /media/wrolpi