[Bug]: [macOS 27 / Apple Silicon] Herd PHP-FPM crashes on every outbound DNS/HTTP request: SIGABRT “multi-threaded process forked” causes 502 across all PHP versions

[edgardluz]

Platform

macOS

Operating system version

macOS 27.0 (26A5388g), Apple Silicon

System architecture

ARM64 (M1, M2, etc)

Herd Version

Herd 1.29.0 (65)

PHP Version

PHP versions 8.3, 8.4, and 8.5

Bug description

The stack excerpt above

php85-fpm-2026-07-28-100551.0004.txt

Steps to reproduce

direct Herd FPM returns 502; php artisan serve works

Relevant log output

[cary-opcenter]

Update: I isolated this further. Herd PHP 8.1 is statically built, so I cannot disable extensions individually via conf.d. However, changing DB_HOST from hostname to direct IP stopped the auth 502 loop (multiple consecutive POST /api/v2/authentication calls returned 200). Crash signature remains php81-fpm SIGABRT with OBJC fork-pre-exec when using hostname. This points to a DNS/hostname-related crash path in Herd FPM on macOS 27, not app auth logic.

---

I can reproduce the same 502 crash loop on Herd with PHP 8.1, and this appears to be a Herd PHP-FPM/runtime crash rather than an application-level exception.

Environment:

Herd version: 1.29.0
PHP version: 8.1.34 (Herd bundled php81-fpm)
Machine: Apple Silicon (Mac14,9)
macOS: 27.0 (build 26A5388g)
App stack: Laravel app behind Herd Nginx/FPM

Symptoms:

Login-related POST requests intermittently or consistently return 502 Bad Gateway.
Herd Nginx log repeatedly shows:
upstream prematurely closed connection while reading response header from upstream
FPM log shows children exiting on SIGABRT and respawning.

Crash evidence from macOS DiagnosticReports:

Process: php81-fpm
Signal: SIGABRT
Termination namespace: OBJC
ASI includes:
multi-threaded process forked
crashed on child side of fork pre-exec

Important isolation result:

Same endpoint succeeds (HTTP 200) when bypassing Herd and using Laravel built-in server on PHP 8.1 (Same as OP):
php artisan serve --host=127.0.0.1 --port=8081
Same endpoint fails (HTTP 502) through Herd repeatedly.
This strongly points to Herd PHP-FPM path, not app code or credentials/validation logic.

What I tested and outcome:

Herd restart: no durable fix.
Set OBJC_DISABLE_INITIALIZE_FORK_SAFETY in FPM/launchctl: no fix.
Disabled Herd 8.1 extension herd-81-arm64.so: no fix.
Disabled Herd auto_prepend_file dump-loader.php: no fix.
Redis/session backend healthy (no outage indicated).
No obvious macOS permission block:
TCC access results are allowed (result 1)
binaries are signed/notarized
no quarantine flags found

[ugd]

Additional reproduction on Herd 1.30.0 and temporary workaround

Environment

• macOS 27.0
• Apple Silicon / ARM64
• Herd 1.30.0
• PHP 8.4
• Laravel served natively through Herd Nginx + PHP-FPM

Symptoms

Laravel requests performing outbound DNS/HTTP calls returned 502 Bad Gateway.

Depending on the frontend, this could be misleadingly reported as a CORS error because
PHP-FPM terminated before returning any HTTP headers.

Herd's Nginx log showed:

upstream prematurely closed connection while reading response header from upstream

The macOS crash report showed:

• php-fpm
• SIGABRT
• termination namespace OBJC
• multi-threaded process forked
• crashed on child side of fork pre-exec

Relevant stack path:

getaddrinfo -> Network.framework -> php_network_getaddresses -> outbound HTTP client

Things that did not fix it

• Updating to Herd 1.30
• Restarting Herd
• Changing application CORS settings
• Disabling Herd's PHP support extension
• Setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY

Temporary workaround

We kept Laravel served natively by Herd but moved the external DNS and TLS connection
out of PHP-FPM.

A local Herd Nginx reverse proxy was added on a loopback address:

server {
    listen 127.0.0.1:18080;
    server_name 127.0.0.1;

    location / {
        proxy_ssl_server_name on;
        proxy_ssl_name external-service.example.com;
        proxy_set_header Host external-service.example.com;
        proxy_pass https://external-service.example.com;
    }
}

The Laravel application was configured to call the local numeric endpoint:

EXTERNAL_SERVICE_URL=http://127.0.0.1:18080

After fully quitting and reopening Herd, PHP-FPM connected only to 127.0.0.1, while
Herd's Nginx handled external hostname resolution and HTTPS communication.

#### Result

- Outbound requests completed successfully.
- PHP-FPM no longer crashed for the proxied service.
- API requests returned normal HTTP responses instead of 502.
- Laravel remained served natively by Herd; php artisan serve was not required.

#### Limitation

This is a service-specific workaround, not a general fix. Every affected external
hostname may require a corresponding local proxy configuration. Outbound connections
made directly by PHP-FPM can still trigger the macOS crash.

[bogdan-mihalcea]

Same crash here, with some extra diagnosis that might help.

Env: macOS 27.0 (26A428), Apple Silicon (arm64), Herd 1.30.0, isolated PHP 7.4
(so this is genuinely all versions, not just 8.3–8.5).

Symptom: any request whose PHP makes an outbound DNS/HTTP call → nginx 502.
Requests with no outbound call are fine. Crash reports are php74-fpm SIGABRT:

• termination: {namespace: OBJC}
• faulting stack: _objc_fatal → performForkChildInitialize →
  (Network.framework) nw_path_is_ultra_constrained_allowed, i.e. the ObjC
  fork-safety abort on the worker's first outbound connection.

The usual OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES workaround does not work via Herd,
even though performForkChildInitialize is exactly what that flag disables. It only
matters in the php-fpm master's environment (workers inherit libobjc's already-
initialized fork-safety state via fork). I tried:

1. env[OBJC_DISABLE_INITIALIZE_FORK_SAFETY] = YES in the isolated pool conf —
   no effect (FPM applies env[] to workers after fork), and herd isolate
   regenerates the pool conf and wipes the line.
2. launchctl setenv OBJC_DISABLE_INITIALIZE_FORK_SAFETY YES + full Herd relaunch —
   the var reaches Herd.app's own env, but the php-fpm master Herd spawns does
   not inherit it (ps eww <master-pid> shows it absent). Herd constructs the
   FPM child env and drops OBJC_*.

It isn't hardened-runtime stripping — Herd.app has
com.apple.security.cs.allow-dyld-environment-variables; the var just isn't passed through.

Request: could Herd set OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in the environment
of the php-fpm master it launches (or expose a supported FPM-master env setting that
survives herd isolate)? That's the only place the flag has any effect.

CLI is unaffected (php artisan serve works) since there's no FPM master→worker fork.

---

Diagnosis investigated and drafted with Claude Code.