We have seen in CI jobs that calling the DB upgrade script from debian/postinst does not work reliably.
When doing a fresh install of osmo-hlr, it usually works as expected:
Setting up osmo-hlr (1.9.2) ... osmo-hlr-post-upgrade: nothing to do (no existing database)
But sometimes:
Setting up osmo-hlr (1.9.2) ... osmo-hlr-post-upgrade: database upgrade is required osmo-hlr-post-upgrade: stopping osmo-hlr service osmo-hlr-post-upgrade: creating backup: /var/lib/osmocom/hlr.db.20260706135658.bak osmo-hlr-post-upgrade: performing database upgrade <0001> db.c:600 using database: /var/lib/osmocom/hlr.db <0001> db.c:103 (283) recovered 4 frames from WAL file /var/lib/osmocom/hlr.db-wal <0001> db.c:679 Database '/var/lib/osmocom/hlr.db' has HLR DB schema version 0 <0001> db.c:103 (1) duplicate column name: last_lu_seen in "ALTER TABLE subscriber ADD COLUMN last_lu_seen TIMESTAMP default NULL" <0001> db.c:248 Unable to prepare SQL statement 'ALTER TABLE subscriber ADD COLUMN last_lu_seen TIMESTAMP default NULL' <0001> db.c:318 Unable to update HLR database schema to version 1 <0001> db.c:685 Failed to upgrade HLR DB schema to version 1: (rc=1) duplicate column name: last_lu_seen <0000> hlr_db_tool.c:509 Error opening database
It seems that osmo-hlr can get started before the osmo-hlr-post-upgrade script runs, then starts to create the database with the current schema, and gets stopped before it is done, leading to the failure above.
Rename the script to osmo-hlr-db-upgrade.sh, remove logic for stopping and starting the service and let systemd call it in ExecStartPre. That way we are sure that it runs *before* osmo-hlr starts up.
