From c5fff4ce8366b08669c0c8b6d30b99b94b9fefca Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sat, 12 Sep 2026 16:15:16 +0200 Subject: fix(packaging): the hub unit can start, and nothing carries the migration path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `ExecStartPre` ran `alembic -c /opt/meshbay-hub/migrations/alembic.ini upgrade head`. The build does stage that file, so the path existed and the contents were wrong: `alembic.ini` resolves `script_location` with `%(here)s`, so the copy pointed at `/opt/meshbay-hub/migrations/src/meshbay_hub/db/migrations` — which nothing installs, because the migrations ship inside `meshbay_hub`, in the shared venv. `ExecStartPre` failing stops the unit. A hub installed from the RPM or the DEB could not start at all, and nothing noticed because the one live deployment was assembled by hand — the same shape as the node unit that carried `User=` into the user unit directory. The same `%(here)s` trap was already found once on the server, where a stray `alembic.ini` resolved to a month-old snapshot of the tree. Twice is a trap rather than an accident, so the fix is that the path is no longer written down anywhere: `meshbay-hub migrate` asks the installed package where its own migrations are, which is correct for the RPM, the DEB, a venv and a checkout. The build stages no `alembic.ini`; the repo keeps its own for `alembic revision` and for deploy scripts that already work. `env.py` now prefers a URL the caller resolved over re-reading the environment itself, so `migrate --config` connects with exactly the string the server will — one resolution, not two that agree until they do not. Six tests, three of which fail against the unit as it was. They read the directives rather than the file, because searching the whole thing finds the comment explaining a directive and calls that the directive. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01T4YmK41VsEURWFdop4EEeT --- packaging/systemd/meshbay-hub.service | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'packaging/systemd') diff --git a/packaging/systemd/meshbay-hub.service b/packaging/systemd/meshbay-hub.service index 40cdb98..1a3ca44 100644 --- a/packaging/systemd/meshbay-hub.service +++ b/packaging/systemd/meshbay-hub.service @@ -16,7 +16,14 @@ EnvironmentFile=-/etc/meshbay/hub.env Environment=MESHBAY_DATABASE_URL=postgresql+asyncpg://meshbay:CHANGEME@localhost/meshbay_hub Environment=MESHBAY_HUB_KEY=/etc/meshbay/hub_private.pem -ExecStartPre=/opt/meshbay-common/venv/bin/alembic -c /opt/meshbay-hub/migrations/alembic.ini upgrade head +# The hub's own command, not `alembic -c `. That path was +# /opt/meshbay-hub/migrations/alembic.ini, where `%(here)s/src/meshbay_hub/db/…` +# resolves to a directory the package does not install — the migrations ship +# inside meshbay_hub itself, in the shared venv. So this line could never +# succeed, and a hub installed from the RPM or the DEB would not start at all. +# `migrate` asks the installed package where its own migrations are, which is +# correct for the package, a venv, and a checkout alike. +ExecStartPre=/opt/meshbay-common/venv/bin/meshbay-hub migrate --config /etc/meshbay/hub.toml ExecStart=/opt/meshbay-common/venv/bin/meshbay-hub --config /etc/meshbay/hub.toml Restart=always RestartSec=5 -- cgit v1.2.3