@tucksaun do you have an idea how to make the socket bulletproof that it gets stopped 🤔. I didn't encountered a problem yet it stopped smoothly 🤔

if it always stops smoothly it means we did our job well with @fabpot :D

More seriously, if you want to simulate this situation: kill -9 the Symfony CLI binary process and remove the PID file associated with FPM (not the one in $HOME/.symfony5/var but in the subdirectory instead).
You will end up with an FPM process that the CLI is not aware of.

Currently, this means there's a 'ghost' process, but at least restarting the web server will spawn a new FPM process and it will work for the end user.
With a fixed listen address, the user gets this kind of error:

$ /Users/tucksaun/Work/src/github.com/symfony-cli/symfony-cli/symfony-cli serve
Following Web Server log file (/Users/tucksaun/.symfony5/log/2b298b2015661d81fcd2d5dcb5ddbe7e15d7b653.log)
Following PHP-FPM log file (/Users/tucksaun/.symfony5/log/2b298b2015661d81fcd2d5dcb5ddbe7e15d7b653/53fb8ec204547646acb3461995e4da5a54cc7575.log)
{"level":"error","time":"2022-11-24T17:26:15-05:00","message":"Unable to start PHP-FPM"}

 [ERROR] PHP-FPM failed to start:
 unable to bind listening socket for address '127.0.0.1:54292': Address already in use (48)
 FPM initialization failed



  PHP server exited unexpectedly: command "PHP-FPM" failed early: exit status 78

and the entire tree is gone for me 🤔

it depends on the parent behavior and how process reaping is done and if children are killed or not.

So my idea would be:

• We enable pid in php-fpm
• Before php-fpm starting, look for that pid file and get the pid and kill it and cleanup that file

What do you think? I guess it should solve it

I have the feeling that would complexify the server management code as it would introduce a special case for FPM.

The philosophy so far has been to clean up a maximum so that the CLI does not leak things but if on a rare occasion it does this is not a big deal as it is not written for production workloads.
So with that in mind, I would probably add a random seed as a suffix to the FPM socket path to be sure the process can always start.
As such, in case of failure, the best case is if the PID file and FPM are still there, the current code will kill the server before going on, but if the PID file or the FPM is not there the CLI will still be able to start.

wdyt?