felhom.eu/REPORT-immich-first-start-2026-09-30.md

REPORT — 2026-09-30 (late afternoon): immich's first start, the cause and the fix; STATUS golden line; R-730, R-731

part	outcome	why / where
A cause	done — up to 9 concurrent geodata INSERTs need ~400 MB anon + ~170 MB touched shared_buffers; 512M fits only with swap. Control pair: swap alone → pass, limit alone → pass, shared_buffers alone → still killed	audits/immich-first-start-2026-09-30/A-cause.md
B fix + proof	done — catalog 56c4888: v3.2.4 + immich-postgres 768M, mem_limit 4480M. Fresh installs, swap OFF: bench ×2 and 9202, 0 kills, anon ≤ 54 %. Step: bench proven (10-min watch, 0 kills), box done 58.5 s, read back, running limit 768M	bench/, box/
C STATUS + register	done — the golden line corrected; R-732 closed	STATUS.md
D1 R-730	done — the ISO build refuses a dirty/unpushed tree; red-proof run; iso-v<version>	scripts/iso/test/clean-tree.sh
D2 R-731	done (narrowed) — gitea 28.0.0 is GA; mariadb 13.0 is a short-term line; the standing shape-switch control NOT built	D/D2-release-checks.txt

No controller, agent or hub release. No bake (none is due).

Claims in the brief, checked

• "the limit is 512M and the header says 256M" — right (and mem_limit 4096M was already 128 MB under the sum of the four limits).
• "no shm_size" — right; /dev/shm 64M, 1.1M used — not involved, so none was added.
• "the image sizes memory from host RAM" — wrong: shared_buffers 512MB and work_mem 16MB are FIXED in the image's own postgresql.conf; the rest are PostgreSQL defaults.
• "bench and box differ by host RAM" — wrong: both on demo-hp. They differ by swap (box 512 MiB, bench 0), proven by giving the bench swap alone.
• "no bake is due" — right (the gate: newest golden baked 0.283.1, OK).
• "the fix reaches installed apps only through the v3.2.4 step" — right, and more: the step itself RE-RUNS the geodata import (228 294 → 228 571 places), so publishing v3.2.4 without the fix would have killed the database during the update.

Per-box cost

+256 MB on immich's database limit (512M → 768M); the declared mem_limit goes 4096M → 4480M (+384, of which 128 corrects an old undercount). Only boxes with immich.

What an installed immich gets, and when

An immich on 3.2.2 keeps 512M until its next guarded Update, which moves it to v3.2.4 with 768M in one step (measured on 9202: running limit 805306368 after). The night leg takes that step only when a fresh whole copy exists (the step carries files_may_change — R-734); otherwise the household's button does. A 3.2.2 immich's own first start is already behind it.

Rows

Register 364 → 366. Closed: R-732, R-730. Narrowed: R-731. Notes: R-676. Opened: R-733 (the bench has no swap, the boxes do; a customer guest's swap is not recorded), R-734 (immich's .immich markers set files_may_change).

Teardown (three layers)

• Machine: 9202 — immich removed through the product (no volume left; its drive folder kept by R-442's refusal, as before), controller.yaml restored (live catalog, read back), swap back at 512 MiB (it was 0 for the one fresh-install proof).
• Host: bench LXC 9401 destroyed, template removed, host temp files removed; drill repo reset to the live main (56c4888), image lines identical.
• Hub: not touched.