Skip to content

Commit 35d4e5c

Browse files
committed
deploying: replace the binary by rename, and prove it execs before restarting
Tonight's deploy silently did not happen. `cp` onto the live path writes new bytes into the EXISTING inode, and macOS caches code-signature validation per vnode -- so the next exec found bytes that did not match the cached verdict and the kernel SIGKILLed it. No output, no error, exit 137. Every surface kept saying the deploy worked. `ck module status` reported ok with 9 serving, because the supervisor was still running the OLD image; buildCommit was the only field that disagreed, and only because I compared it. The single tell anywhere was `last_exit: sig9` in the supervisor row, which nothing directs a reader to. Two changes. The copy is now cp-then-mv, so the live path gets a NEW inode with no cached verdict and no window where the file is absent. And a one-second exec check runs before the restart: a binary that cannot execute is caught at the step that placed it, rather than in the verify step with a supervisor that has already fallen back to an image nobody chose. Mechanism confirmed rather than assumed: a fresh copy execs (exit 0), the same file with one byte overwritten in place is SIGKILLed (exit 137). This is the per-vnode caching measured during the syspolicyd work, arriving through the one door the runbook opened every single deploy.
1 parent 47e7cfe commit 35d4e5c

1 file changed

Lines changed: 15 additions & 2 deletions

File tree

‎docs/deploying.md‎

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -15,9 +15,22 @@ rather than inferred.
1515
# 1. build
1616
cargo build --release
1717

18-
# 2. back up what is running, then replace it
18+
# 2. back up what is running, then replace it BY RENAME, never by overwrite.
19+
# `cp` onto the live path writes new bytes into the EXISTING inode, and macOS
20+
# caches code-signature validation per vnode -- so the next exec finds bytes
21+
# that do not match the cached verdict and the kernel SIGKILLs it. Silently:
22+
# no output, no error, exit 137, and `ck module status` keeps reporting `ok`
23+
# from the process that is still running the OLD image. That is a deploy that
24+
# did not happen while every surface says it did; the only tell is
25+
# `last_exit: sig9` in the supervisor row.
1926
cp ~/.local/share/cortexkit/bin/ck-insula ~/.local/share/cortexkit/bin/ck-insula.bak
20-
cp target/release/ck-insula ~/.local/share/cortexkit/bin/ck-insula
27+
cp target/release/ck-insula ~/.local/share/cortexkit/bin/ck-insula.new
28+
mv -f ~/.local/share/cortexkit/bin/ck-insula.new ~/.local/share/cortexkit/bin/ck-insula
29+
30+
# 2b. prove the file you just placed can EXECUTE before restarting anything.
31+
# One second, and it is the difference between finding this now and finding
32+
# it in step 4 with a supervisor that has already fallen back.
33+
~/.local/share/cortexkit/bin/ck-insula --version # must print, must exit 0
2134

2235
# 3. restart under supervision
2336
ck module restart insula

0 commit comments

Comments
 (0)