Repository navigation
Commit 35d4e5c
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
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
15 | 15 | | |
16 | 16 | | |
17 | 17 | | |
18 | | - | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
19 | 26 | | |
20 | | - | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
21 | 34 | | |
22 | 35 | | |
23 | 36 | | |
| |||
0 commit comments