fix(server): re-sign bundled llama-server on darwin to survive macOS amfid#34
Closed
fix(server): re-sign bundled llama-server on darwin to survive macOS amfid#34
Conversation
…amfid macOS Sequoia (26+) tightened the amfid (AppleMobileFileIntegrity) policy: ad-hoc-signed binaries whose linked dylibs carry stale signatures or a com.apple.provenance xattr from the previous bundle get SIGKILL'd within milliseconds of execve. Symptom in the supervisor: `signal: killed` with empty stderr (kill happens before the child can write a single byte), followed by exhausted restart budget and the boot path failing with "embeddings: llama-server not ready: context deadline exceeded". Root cause is that `cp -R $(LLAMA_DIR)/. $(BUNDLE_DIR)/llama/` in the existing `bundle:` target creates new files macOS treats as untrusted; whatever blessing the previous bundle had does not carry over. So the fix has to run on every bundle, not just first install. Wraps the strip + deep re-sign in `ifeq ($(OS),darwin)` so other platforms are unaffected. Tested with two consecutive `make bundle` + direct llama-server invocation cycles — both stay alive past the first metal_library_init log line where the previous behaviour died. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Owner
Author
|
Folded into #33 — shipping the Makefile fix together with the version-check feature so dev-box survives end-to-end on macOS Sequoia. |
12 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
com.apple.provenancexattr from the previous bundle get SIGKILL'd within milliseconds ofexecve.{"level":"WARN","msg":"llama-server exited unexpectedly","err":"signal: killed"}with empty stderr (kill happens before the child can write a single byte), restart loop exhausts budget after 4 attempts, boot path fails withembeddings: llama-server not ready: context deadline exceeded.bundle:target copiescp -R $(LLAMA_DIR)/. $(BUNDLE_DIR)/llama/—cpcreates new files which macOS treats as untrusted regardless of what state the source had. Whatever blessing the previous bundle accumulated doesn't carry over.make bundle, gated behindifeq ($(OS),darwin)so other platforms are unaffected.Diagnosis trail (for the record)
Confirmed via:
llama-serverinvocation outside the supervisor → samesignal: killed, exit 137, empty stderrxattr -lshowedcom.apple.provenanceon every dylib (auto-applied by macOS on file creation)codesign --force --deep --sign -once → first run works, subsequent runs killed (signature on dylibs not propagated by single-binarycodesign)xattr -cr <bundle>/llama/ && codesign --force --deep --sign - <bundle>/llama/llama-server→ both consecutive runs alive (SNstatus, full metal init logs)Test plan
make bundleproduces a working llama-serverggml_metal_library_initmake runboots cleanly without supervisor restart loopmake bundle+make run→ still works (the recurrence-on-rebundle case)ifeq ($(OS),darwin)block skipped, no behavioural changeNotes
This change does not affect Linux Docker images — those use distroless runtime, the binary inside the image is built/copied by the Dockerfile with its own signing/permissions, and amfid is macOS-only. Only matters for
make run/make bundleon macOS dev boxes.🤖 Generated with Claude Code