From 889daacdf8e3a9f1f3a41fe3b546deff1bfbd0ae Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Mon, 5 Oct 2026 09:59:51 +0200 Subject: image-builder: daily registry GC, registry on its own disk On sda2 the registry grew 13G -> 53G between weekly GCs and filled /. That broke /tmp, the build log, buildx state and the GC itself, so every build failed from 2026-10-04. Run registry-gc.sh daily at 07:30 instead of Sundays only. The store has since moved to a dedicated disk with backup=0, out of vzdump. Record that in fstab.example along with two traps hit during the fix: `crontab -` on a full disk silently writes a 0-byte crontab, and a plain docker stop/start leaves the registry serving the old, deleted directory. Co-Authored-By: Claude Opus 5.5 --- image-builder/README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'image-builder/README') diff --git a/image-builder/README b/image-builder/README index a1ea0c4..2594e30 100644 --- a/image-builder/README +++ b/image-builder/README @@ -104,12 +104,12 @@ cleanups keep it bounded: docker image prune -f (daily) removes dangling images left in the docker store when a tag moves to a freshly built image. - registry-gc.sh (weekly) reclaims unreferenced blobs from the + registry-gc.sh (daily) reclaims unreferenced blobs from the registry's own store. registry-gc.sh is deliberately conservative: * it refuses to run while any build script is active, so it can never race a - push (cron runs it at 08:00 Sunday, well after the ~06:30 chain); + push (cron runs it daily at 07:30, after the ~06:30 chain); * it stops the registry so the manifest/blob graph is stable, and restarts it via an EXIT trap even if collection fails part-way; * it deletes only untagged manifests (-m) and the blobs they alone -- cgit v1.2.3