Debugging on Luther Monson

Step Debugging a Worker That Never Ends

Mon, 12 Oct 2026 21:10:00 -0700

Persistent workers are the big performance win in modern PHP. You boot Laravel or Symfony once, keep the container in memory, and serve thousands of requests out of the same process. ePHPm has had a worker mode for a while. Like most worker runtimes it had a quiet hole in it. You couldn’t step debug a request with Xdebug. I wanted that fixed without patching Xdebug and without giving up the warm pool. The answer ended up being to stop fighting the constraint and route around it. The debug lane is merged on main and coming in the upcoming v0.12.0 release.

An Upstream PHP JIT Use-After-Free, and Why Our Default Flipped Twice

Thu, 01 Oct 2026 20:10:00 -0700

In August, ePHPm turned PHP’s tracing JIT on by default in single-site serve mode. Three days later it went back off on every platform, and it’s still off. The reason turned out to be a use-after-free in PHP’s tracing JIT that has nothing to do with ePHPm. Stock php -S with a stock Laravel skeleton dies on it in a couple of requests. The fix is now released upstream. So this seemed like the right time to write up how we got there, and what still has to happen before the default can flip again.

os/exec's StdoutPipe Footgun: How cmd.Wait() Ate My Last Frame (Twice)

Thu, 17 Sep 2026 20:12:00 -0700

shipmates spends most of its life spawning claude (and codex) processes and reading newline-delimited JSON off their stdout. The last frame of a turn is the important one. It’s a result frame with the cost, the model and the final text. Stderr matters too, because that’s where Claude Code tells you Invalid API key · Please run /login. For a while I was throwing both away under load. The cause is documented right there in the os/exec godoc. I fixed it in one package and then found the exact same bug again a month later in another.

OPcache on Windows: Two Silent Failures

Sat, 29 Aug 2026 16:45:00 -0700

Windows is the platform where ePHPm gets the least traffic and the most surprises. Last week closed out two OPcache bugs that only exist there. Both were quiet in their own way. One killed the server at startup with nothing in our own logs. The other didn’t kill anything. It just ran PHP 8.3 with no opcode cache at all. For three weeks after a fixed SDK was published, every check stayed green.

Requests That End Wrong: A 200 That Was Really a Crash

Thu, 13 Aug 2026 21:14:00 -0700

The scariest response a server can send isn’t a 500. It’s a 200 that should have been a 500. A crash is loud. The pod restarts, an alert fires, somebody looks. A truncated page with a success status code is quiet. Your CDN caches it and the health check calls the box healthy. A client parses half a document as if it were the whole thing.

ePHPm embeds PHP inside a Rust server. So we own the part of PHP that php-fpm normally owns: starting a request, running the script and ending it. Over the last couple of months I’ve fixed three bugs that all live in that start-and-end code. None of them were in the SAPI I/O callbacks like ub_write and read_post, where you’d expect to find embed bugs. They were in the Zend request lifecycle and in TSRM teardown. That’s code you never touch when you run PHP behind php-fpm.

Rescuing a Windows Dynamic Disk Over USB with WSL2 and USB/IP

Sat, 01 Aug 2026 13:15:00 -0700

I pulled a 1 TB NVMe out of an old Windows box, dropped it in a USB enclosure and plugged it in. Windows showed nothing. No drive letter, no “initialize this disk” prompt, nothing in Explorer. Disk Management listed it as Invalid. The enclosure’s booklet said to “bring the disk online”, which silently did nothing. The data was completely intact. Windows was refusing on policy grounds, not because anything was broken. Getting it back meant going around the Windows storage stack entirely. I handed the raw USB device to a Linux kernel that doesn’t share Windows’ opinions.

PHP Signal Safety - The Init Ordering Bug Nobody Warns You About

Sun, 12 Apr 2026 20:15:00 -0700

Last week I wrote about why ePHPm embeds PHP from Rust and promised the signal bug its own post. Here it is. It’s the kind of bug where the fix is about ten lines and the explanation is the whole post. Nothing in PHP’s embed documentation (there’s barely any) tells you that initializing PHP has process-wide side effects. Those side effects assume PHP is the only thing in the process.

The setup

The first working version of ephpm serve looked like every async Rust program. It was #[tokio::main]-style. Build the runtime, then inside it load config, initialize PHP and start the HTTP server. PHP requests run on spawn_blocking threads. Simplified: