I spent a full day on a "five-minute" Docker migration — PHP-FPM exit 139 on Colima
We moved off Docker Desktop to Colima ahead of the licensing changes. The migration was supposed to be boring. Then PHP-FPM started dying with exit code 139 (SIGSEGV) about a second after start — no logs, no core dump, no error. PHP CLI was fine, six thousand unit tests passed. Only the FPM master crashed.
The cause, three layers down:
- OPcache asks the kernel for huge pages when its shared memory size is a multiple of 2 MB —
mmap()withMAP_HUGETLB. - Docker Desktop's kernel rejects that cleanly, and OPcache just falls back to normal memory. Nothing to see.
- Colima's kernel has huge page support compiled in. It starts the mapping, unmaps the old range, and then fails with
ENOMEM. A correct kernel should never do this — a failedmmap()is supposed to leave the old memory untouched. - Under Rosetta 2, that hole isn't empty. The process touches it and dies.
The fix: a seccomp profile that returns EPERM for any mmap() carrying the huge-page flag — the same clean "no" Docker Desktop's kernel already gives. Two rules on top of Docker's default seccomp profile, applied machine-wide in colima.yaml, so there's no need for per-repo overrides.
A few things that do not help, in case you go looking: JIT settings, vm.overcommit_memory, ASLR. Enabling huge pages properly inside the VM is a trap too — php-fpm stops crashing and starts hanging instead, which is arguably worse.
Full write-up with the seccomp profile, a two-line curl+jq snippet that builds it from Docker's default, and the smaller escape hatches (opcache.memory_consumption=65, preferred_memory_model=shm):
https://blog.crazy-goat.com/en/colima-php-fpm-segfault-exit-139/?utm_source=reddit
[link] [comments]