macOS: use posix_spawn instead of fork+exec for child processes and patch HOME so its not null and doesn't throws a segfault in llama.cpp

[Geramy]

Problem: lemond spawns llama-server via fork()+execvp(). On macOS, fork() leaves the child with corrupted Mach-port and XPC-bootstrap state that execvp() does not reset. llama.cpp b8884+ now runs a ggml-metal probe at startup that calls [MTLDevice newLibraryWithSource:] — which routes through MTLCompilerService XPC — and dies on the broken channel before the model is opened. Direct terminal runs work; only lemond-spawned children fail (~130ms, exit code -1).

Fix: on APPLE, replace fork()+execvp() with posix_spawn. Preserves pipe/working-dir semantics. Adds POSIX_SPAWN_CLOEXEC_DEFAULT to avoid leaking lemond FDs into the child, and POSIX_SPAWN_SETSIGDEF to reset inherited SIG_IGN dispositions. Linux and Windows paths unchanged.

[Geramy]

Back story not needed really but very informational and nice to have.

Why fork() is unsafe under Apple frameworks
This is a long-documented Apple platform rule. The most authoritative source is Apple's own open-source Objective-C runtime (objc4). From runtime/objc-initialize.mm (apple-oss-distributions/objc4), in the comment block titled "Fork Safety or: We Tried So Hard":

"It is impossible to make +initialize fork-safe in the general case. The standard approach of acquiring all locks pre-fork doesn't work, because another thread might be in +initialize waiting on the thread calling fork, and trying to wait for that to complete would result in a deadlock."

The child-side function performForkChildInitialize (same file) prints the familiar runtime error:

"+[%s initialize] may have been in progress in another thread when fork() was called."

and calls objc_initializeAfterForkError(cls) before crashing. The kill switch OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES is the existence proof — Apple explicitly shipped a per-process override because they know fork-then-exec leaves children in an unrepresentable runtime state. It doesn't fix the underlying corruption, it just silences the abort.

The same unsafety extends to CoreFoundation (Mach ports and XPC bootstrap handles don't reset across fork), Grand Central Dispatch (pthread workqueue state), and the higher-level frameworks that sit on top of them — including Metal. exec() replaces the memory image but does not reset Mach ports, XPC connections, dispatch queues registered with the kernel, or pthread workqueue bookkeeping.

Apple's documented alternative is posix_spawn(2). From Apple's local man page (man posix_spawn on any macOS system):

"The posix_spawn() function creates a new process from the executable file, called the new process file, specified by path… File descriptors open in the calling process image remain open in the new process image, except for those for which the close-on-exec flag is set…"

The important distinction is that posix_spawn creates the child without the "inherit all parent state then selectively discard it" semantics of fork+exec. Under the hood on Darwin it's a single kernel transaction that builds a fresh process context, so Mach-level state doesn't leak in.

[Geramy]

setting HOME here to help mitigate llama.cpp but for macOS, but realistically it should be fixed in llama.cpp -> PR ggml-org/llama.cpp#22263

[jeremyfowers]

@claude review

[github-actions]

Claude finished @jeremyfowers's task in 2m 0s —— View job

---

PR Review

• Gather context
• Read changed files
• Analyze implementation
• Post review feedback

---

The motivation is solid and the posix_spawn approach is the right call for macOS. A few issues below, one of which is a real behavioral regression.

---

Bug: stdout/stderr lost when inherit_output && !filter_health_logs

src/cpp/server/utils/process_manager.cpp ~line 453

The file-actions block has three branches:

if (inherit_output && filter_health_logs) {
    // pipes → dup2 into stdout/stderr   ✓
} else if (!inherit_output) {
    // /dev/null redirect                ✓
}
// inherit_output && !filter_health_logs → nothing added  ← bug

Because POSIX_SPAWN_CLOEXEC_DEFAULT closes every parent fd in the child (including fd 1 and fd 2) unless they are explicitly mentioned in a file_actions call, when this path is taken the child starts with no stdout and no stderr. The fork+execvp path inherits them naturally, so this is a silent regression — e.g., in debug mode when filter_health_logs is false, no backend output will appear.

Fix: add an explicit else branch that dup2s each fd onto itself (the Apple-documented trick to "opt in" an fd when POSIX_SPAWN_CLOEXEC_DEFAULT is active):

} else {
    // inherit_output && !filter_health_logs
    // POSIX_SPAWN_CLOEXEC_DEFAULT would otherwise close these in the child
    posix_spawn_file_actions_adddup2(&file_actions, STDOUT_FILENO, STDOUT_FILENO);
    posix_spawn_file_actions_adddup2(&file_actions, STDERR_FILENO, STDERR_FILENO);
}

Stdin (fd 0) has the same issue for completeness, but backend processes don't read stdin so it's low priority. Fix this →

---

Minor: getpwuid is not thread-safe

src/cpp/server/backends/llamacpp_server.cpp ~line 449

struct passwd* pw = getpwuid(getuid());

getpwuid uses a static internal buffer and is not async-signal-safe or thread-safe. The Router serves concurrent HTTP requests and load() can be called from different threads. Use getpwuid_r instead:

struct passwd pw_buf{};
struct passwd* pw = nullptr;
char pw_str_buf[4096];
getpwuid_r(getuid(), &pw_buf, pw_str_buf, sizeof(pw_str_buf), &pw);
std::string fallback_home = (pw && pw->pw_dir) ? pw->pw_dir : "/var/root";

Fix this →

---

Nit: stdin not inherited in pipe case

When inherit_output && filter_health_logs, the pipe setup closes stdin (fd 0) in the child via POSIX_SPAWN_CLOEXEC_DEFAULT — it's never mentioned in file_actions. The fork path inherits stdin. This is almost certainly harmless for HTTP server backends, but it's a behavioral difference worth being aware of.

---

Everything else looks good

• The core posix_spawn rationale is correct and well-explained.
• POSIX_SPAWN_CLOEXEC_DEFAULT | POSIX_SPAWN_SETSIGDEF is the right combination of flags.
• The env-var merging logic (strip overrides from environ, then append env_vars) is correct.
• The addchdir_np with #pragma clang diagnostic suppression is the right approach while older SDKs remain in scope.
• The HOME fallback via getpwuid is correct in logic (just needs the thread-safe variant).
• The metal version bump to b8884 is the expected prerequisite for this fix.
• Test skips in server_env_vars.py are correct.

The stdout/stderr regression should be fixed before merge. The getpwuid_r change is a clean correctness fix worth doing at the same time.

[jeremyfowers]

we're back, baby!