pcntl_fork() in worker thread creates full Go runtime copy that never exits, causing unbounded process accumulation

[skomarchukmojam]

Environment

• FrankenPHP version: 1.12.1
• PHP version: 8.4
• OS: Linux (Debian bookworm, Docker container)
• Caddy config: num_threads 2, max_threads 8

Description

When pcntl_fork() is called inside a FrankenPHP worker thread (during an HTTP request),
the child process becomes a full copy of the FrankenPHP Go runtime and never terminates —
even after calling exit(0) from PHP.

Each request that calls pcntl_fork() leaves one additional frankenphp process
in S (sleeping) state permanently. These processes accumulate indefinitely.

Reproduction

Minimal controller:

$pid = pcntl_fork();
if ($pid === 0) {                                                                                                                                                                                                                 
    usleep(100); // 100 microseconds
    exit(0);                                                                                                                                                                                                                      
}               

Steps:                                                                                                                                                                                                                            
1. Run FrankenPHP with num_threads 2, max_threads 8
2. Hit the endpoint 20 times                                                                                                                                                                                                      
3. Check ps aux inside the container
                                                                                                                                                                                                                                  
Before (20 requests):
3 processes                                                                                                                                                                                                                       
                
After:                                                                                                                                                                                                                            
23 processes — all `frankenphp run` with status `S`, never exit
                                                               
Root cause (hypothesis)                                                                                                                                                                                                           
                                                                                                                                                                                                                                  
pcntl_fork() in a Go-based runtime duplicates the entire Go runtime — goroutines,                                                                                                                                                 
mutexes, thread pools. The child process inherits locks held by threads that no                                                                                                                                                   
longer exist in the child, causing the Go runtime to deadlock on shutdown.                                                                                                                                                        
PHP's exit(0) is called but the Go process cannot clean up and terminate.                                                                                                                                                         
                                                                                                                                                                                                                                  
Impact                                                                                                                                                                                                                            
                                                                                                                                                                                                                                  
In production under load, these zombie-like sleeping processes accumulate rapidly:                                                                                                                                                
- PID exhaustion
                                                                                                                                                                                                                                  
Notes
                                                                                                                                                                                                                                  
- tini as PID 1 does not help — processes are in S state, not Z (zombie),                                                                                                                                                         
so tini has nothing to reap
- Process::run() (Symfony/Laravel, uses proc_open) does not reproduce the issue                                                                                                                                                   
- Only direct pcntl_fork() call reproduces it                                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                  
Question                                                                                                                                                                                                                          
                                                                                                                                                                                                                                  
Is pcntl_fork() expected to be unsupported inside FrankenPHP worker threads?                                                                                                                                                      
Should FrankenPHP disable pcntl_fork or emit a warning when called in worker context?
                                                                                                                                                                                                                                  
---             

[withinboredom]

This is expected. A fork() creates a copy of the process not the thread -- this would be an entire copy of Frankenphp.

[withinboredom]

Potential feature: override pcntl_fork to spawn from the non-worker thread pool.

[skomarchukmojam]

@withinboredom
Thank you for the quick response!

We are running FrankenPHP in production with a Laravel application and are observing
exactly this behavior.

The process count grows unboundedly until the pod hits resource limits and needs to
be killed OR restarted server pod.

Since this is expected behavior - is there a recommended solution for Laravel applications
running on FrankenPHP right now?

Laravel (and Symfony Process component) use pcntl_fork() internally in several places.
Does this mean Laravel is fundamentally incompatible with FrankenPHP worker mode,
or is there a workaround (e.g. intercept fork calls, disable pcntl, offload to a
separate process pool)?

[henderkes]

I'm brainstorming for a solution that doesn't require us to override every function that forks...

[withinboredom]

Short of adding hooks into pcntl, I can't think of any. I've never compiled frankenphp with pcntl (it seems fundamentally incompatible with frankenphp IMHO -- threads vs. process and pcntl would allow you to put the entire frankenphp process into bad states).

[henderkes]

Even adding hooks to pcntl, I don't think there's anything we can do that makes this a possibility. Either we intentionally break pcntl_fork to spawn a fresh process (-> different behaviour), or we do fork. If we do fork, the child will have inherited a broken Go runtime. Even if we override exit() to instead force exit the child, the second it attempts to do any call that crosses the Cgo boundary, bad things will happen.

Spawning a new thread instead doesn't work as a drop-in replacement either, because the engine will be at a different state for that thread.

[Ferikl]

The root of this issue is - we are running big laravel application and there is no direct calls of pcntl.
We had an errors after few hours:

Curl error: #6 - getaddrinfo() thread failed to start

we investigated that

>ls /proc | grep -c '^[0-9]'
shows 9k+

[skomarchukmojam]

@withinboredom
I would agree with that if the fork was coming from our custom code -
we could simply refactor it. But pcntl_fork() is used internally in
Laravel and Symfony core components, not in userland code.

Given that FrankenPHP positions itself as a drop-in replacement for PHP-FPM
for Laravel and Symfony apps, I would expect some built-in safeguard against
unbounded process accumulation when fork is called from a worker thread
even if full pcntl support is fundamentally incompatible with the Go .

Whether that's a warning, graceful child termination, or clear documentation
on which framework features are incompatible — anything would help avoid
silent process exhaustion that is very hard to diagnose in production.

[henderkes]

Given that FrankenPHP positions itself as a drop-in replacement for PHP-FPM for Laravel and Symfony apps, I would expect some built-in safeguard against unbounded process accumulation when fork is called from a worker thread even if full pcntl support is fundamentally incompatible with the Go .

I'm like 99.99999999% sure that Symfony doesn't use pcntl_fork in the core framework anywhere and I'd be extremely surprised if Laravel did in a HTTP Context either.

Whether that's a warning, graceful child termination, or clear documentation on which framework features are incompatible — anything would help avoid silent process exhaustion that is very hard to diagnose in production.

Could you link me to what actually is incompatible?

Edit:

• Symfony has one reference to it in a TEST: https://github.com/search?q=repo%3Asymfony%2Fsymfony%20pcntl_fork&type=code
• Laravel has zero references to it: https://github.com/search?q=repo%3Alaravel%2Flaravel%20pcntl_fork&type=code

[skomarchukmojam]

@henderkes You're right, I was wrong about the core framework, thanks for checking.

The reference I was thinking of is laravel/prompts Spinner:
https://github.com/laravel/prompts/blob/main/src/Spinner.php#L62

It uses pcntl_fork() for the animation loop when spin() is called typically CLI,
but any userland code or third-party package (via pcntl_fork() directly, Process::run(),
or other wrappers) running inside a FrankenPHP worker could trigger this silently.

Unfortunately, we haven't been able to identify the exact call site in our codebase —
it only reproduces in production and we're still trying to catch which user request
triggers this behavior.

That's the core ask: even something as simple as a warning when pcntl_fork() is called
from a worker thread would let us catch it in development rather than diagnosing silent
process exhaustion in production.

Is there any hook or debug mode we could enable today to detect fork calls at runtime?

Also will be waiting #2331 (comment)

[Ferikl]

@henderkes Seems like not only pcntl_fork make this dirty job, we spotted same behavior with Yii2 :( can it be curl lib?

[henderkes]

The reference I was thinking of is laravel/prompts Spinner: https://github.com/laravel/prompts/blob/main/src/Spinner.php#L62

That most certainly shouldn't be used outside of CLI context. Fwiw this will behave ill under Apache, ngx, or any other process embedding a php runtime, too, even if it may not lead to sleeping, deadlocked processes.

Seems like not only pcntl_fork make this dirty job, we spotted same behavior with Yii2 :( can it be curl lib?

Curl doesn't fork processes, so no. Will need more info on a reproducer where pcntl_fork isn't called.

[henderkes]

Potential feature: override pcntl_fork to spawn from the non-worker thread pool.

I don't think this would change anything. I may however have to correct myself - as long as the parent is alive, the forked child should be able to do Cgo calls perfectly fine. So we may get away with only overwriting the exit path of children processes to skip runtime cleanup and just leave that to the OS. Not great for monitoring of course, but maybe force _exit(0) could do the trick...>

I don't think it's a "clean" solution, but it might be a solution to what we have reported by people who use frankenphp php-cli bin/console .... too.