Skip to content

Commit c0ced5d

Browse files
Robbie1977claude
andcommitted
Build with --noBuildLock and clear a stale lock first
Hugo takes an flock on .hugo_build.lock at startup and waits for it indefinitely with no message, no error and no timeout. The observed symptom is a build that copies the static files and then stops: 66 files and 16 MB in the staging tree, a sleeping process at near-zero CPU, low RSS, and no further output. Reproduced exactly by holding the lock against an otherwise healthy build. The workspace is on NFS, where a lock left by an uncleanly killed build outlives the process that took it, so this recurs on its own. The lock also guards against a concurrent second build, which cannot happen here: the container is the only builder and Rancher runs it start_once. It protects nothing and fails invisibly. Clear any stale lock file as well, so nothing is left lying around now that Hugo no longer manages it. Verified: with the lock held, the build now completes rather than hanging. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X1AuLA5tHPwpD7Hp5utPkS
1 parent 22843cf commit c0ced5d

1 file changed

Lines changed: 16 additions & 1 deletion

File tree

‎deploy.sh‎

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,22 @@ cd "$SRC"
3737

3838
# ---------------------------------------------------------------- build ------
3939
rm -rf "$STAGE"
40-
hugo --gc --minify --destination "$STAGE"
40+
41+
# --noBuildLock, and a stale lock cleared first.
42+
#
43+
# Hugo takes an flock on .hugo_build.lock at startup and waits for it forever if
44+
# it cannot get one — no message, no error, no timeout. The symptom is a build
45+
# that copies the static files, then hangs: on 2026-08-05 that was ~66 files and
46+
# 16 MB in the staging tree, a sleeping process at near-zero CPU, and nothing
47+
# else for as long as anyone cared to wait.
48+
#
49+
# The workspace is on NFS, where a lock left behind by an uncleanly killed build
50+
# survives the process that took it. And the lock guards against a second
51+
# concurrent build, which cannot happen here: this container is the only builder
52+
# and Rancher runs it start_once. So it protects nothing and its failure mode is
53+
# an invisible hang.
54+
rm -f "$SRC/.hugo_build.lock"
55+
hugo --noBuildLock --gc --minify --destination "$STAGE"
4156

4257
# ---------------------------------------------------------------- gates ------
4358
# Never publish an obviously broken build. The term corpus comes from an API

0 commit comments

Comments
 (0)