Changeset 12bed59 in Klonkt for deploy

Timestamp:

08/07/2026 04:14:49 PM (5 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

f85b2c3

Parents:

fa33214

git-author:

Robin <roboburr@…> (07/31/2026 02:52:19 PM)

git-committer:

Robin <roboburr@…> (08/07/2026 04:14:49 PM)

Message:

Zet de oude klonkt.service opzij; maskeren werkte niet

Correctie op f434294. Daar maskeerde ik de oude unit om te voorkomen dat een
systemctl restart klonkt hem uit de dood liet opstaan. Getest met een
user-unit blijkt dat niet te werken:

Failed to mask unit: File '.../masktest.service' already exists

systemctl mask legt een symlink naar /dev/null op het pad van de unit, maar
install.sh schrijft klonkt.service in /etc/systemd/system, de map met de
hoogste prioriteit. Er is dan geen plek meer om de mask neer te zetten en
systemd weigert. Na de mislukte mask start restart de unit gewoon nog
(exitcode 0), dus de fix deed niets.

Erger: die mask stond zonder vangnet onder set -euo pipefail. In het
migratiescript zou hij de migratie afbreken NADAT de data al verplaatst was.
De fix was dus niet alleen nutteloos maar ook gevaarlijk.

Wat wel werkt, en nu getest is in beide richtingen: het unit-bestand opzij
zetten met een tijdstempel en daemon-reload. systemd kent de unit dan niet
meer, en een restart faalt hard met "Unit klonkt.service not found"
(exitcode 5) in plaats van stilletjes een tweede proces te starten dat een
lege database in de checkout schrijft. Terugzetten plus daemon-reload maakt
hem weer gewoon startbaar, dus de rollback blijft intact.

Changed files:
scripts/klonkt-migrate-data.sh

• eigen stap 'Retiring klonkt.service': stop, disable, bestand naar klonkt.service.retired-<tijdstempel>, daemon-reload
• stop en disable krijgen een vangnet zodat een al gestopte unit de migratie niet afbreekt
• waarom maskeren hier niet kan, staat erbij; dat is niet vanzelfsprekend

scripts/klonkt-refresh-updater.sh

• zelfde aanpak voor al gemigreerde servers, met een expliciete waarschuwing als het verplaatsen niet lukt

deploy/MULTI-INSTANCE.md

• rollback bijgewerkt naar het terugzetten van het bestand

-robo
Co-Authored-By: Claude Fable 5 <noreply@…>

File:

• deploy/MULTI-INSTANCE.md (modified) (1 diff)

deploy/MULTI-INSTANCE.md

@@ -84 +84 @@
 because the port comes from the same `.env`.
 
-**Rolling back.** The old `klonkt.service` is disabled and masked, not deleted.
-Masked because `disable` alone does not stop `systemctl restart klonkt` from
-starting it again, and a resurrected unit no longer finds its `.env` (that moved
-with the data): it would fall back to the defaults and write a fresh empty
-database into the checkout. To go back, move the data into `/opt/klonkt/storage`,
-restore the relative paths in `.env`, then `systemctl unmask klonkt` and
-`systemctl enable --now klonkt`.
+**The old unit is moved aside, not deleted.** It ends up next to its old place
+as `klonkt.service.retired-<timestamp>`. Stopping and disabling is not enough:
+`systemctl restart klonkt` starts a disabled unit anyway, which is exactly what
+an updater generated before the split does. A resurrected `klonkt.service` no
+longer finds its `.env` (that moved with the data), falls back to the built-in
+defaults, and writes a fresh empty database into the checkout. Masking does not
+work here either, because the unit file sits in `/etc/systemd/system` and
+`systemctl mask` refuses while a real file is there.
+
+**Rolling back.** Move the data into `/opt/klonkt/storage`, restore the relative
+paths in `.env`, move the retired unit file back to
+`/etc/systemd/system/klonkt.service`, then:
+
+```bash
+sudo systemctl daemon-reload
+sudo systemctl enable --now klonkt
+```
 
 ## Adding an instance