Closed mattkingshott closed 4 years ago
brew services list php error root /Library/LaunchDaemons/homebrew.mxcl.php.plist
ERROR: Another FPM instance seems to already listen on /Users/[user]/.config/valet/valet.sock
This situation is a result of you having Homebrew configured to run PHP twice: both as root and as non-root. That's why the logs are talking about "when FPM is not running as root" (and mentions [pool valet]) and "Another FPM instance seems to already listen on ... valet.sock":
NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root ERROR: Another FPM instance seems to already listen on /Users/[user]/.config/valet/valet.sock
It is also confirmed by having multiple launchd plists present for starting PHP under different users:
ls -al ~/Library/LaunchAgents -rw-r--r-- 1 matt staff 628 20 Jun 10:09 homebrew.mxcl.php.plist ls -al /Library/LaunchDaemons -rw-r--r-- 1 root admin 628 20 Jun 10:08 homebrew.mxcl.php.plist
Most likely at some point you manually started PHP using brew service start php
(with/without sudo
) instead of letting Valet handle it with "valet start".
The solution is a little cleanup:
brew services stop php
sudo brew services stop php
# The above commands should delete the plists but to be sure, the following removes them as well:
rm ~/Library/LaunchAgents/homebrew.mxcl.php.plist
sudo rm /Library/LaunchDaemons/homebrew.mxcl.php.plist
# now tell Valet to verify the configs are correct and restart things the way it wants it
valet install
# then reboot to be sure things are all restarting as desired
Wow! Thanks so much for all of that. I’ll dig into it 👍🏻👍🏻
Note than php, nginx, dnsmasq all should run as root.
Apply:
brew services stop php
brew services stop nginx
brew services stop dnsmasq
DON'T start the following services manually, instead let valet install
handle it.
if you decide to update the valet package from composer, simply run valet install
everytime after the update.
Hope that helps!
I think my mistake in general was installing some of these things using brew rather than letting valet do it for me. In future, I'll just use brew to install other services e.g. mysql, redis etc.
It does beg the question, what is the process for upgrading php itself e.g. 7.3 to 7.4? Do you just do the upgrade within brew and then run a valet install?
I think my mistake in general was installing some of these things using brew rather than letting valet do it for me. In future, I'll just use brew to install other services e.g. mysql, redis etc.
It does beg the question, what is the process for upgrading php itself e.g. 7.3 to 7.4? Do you just do the upgrade within brew and then run a valet install?
if you did not install a specific version like brew install php@7.3
and used brew install php
then I believe brew upgrade
is enough to upgrade from 7.3 to latest 7.4.x
ah okay. Yes, that's the route I used. I just wondered if that process would create the issue itself.
ah okay. Yes, that's the route I used. I just wondered if that process would create the issue itself.
The issue was due to how the php-fpm service was started. you started the php-fpm service as your user where valet needs it to run as root. Thus the conflict. Hope things are clear now. Good day!
Right got it. Thanks!
I think my mistake in general was installing some of these things using brew rather than letting valet do it for me. In future, I'll just use brew to install other services e.g. mysql, redis etc. It does beg the question, what is the process for upgrading php itself e.g. 7.3 to 7.4? Do you just do the upgrade within brew and then run a valet install?
if you did not install a specific version like
brew install php@7.3
and usedbrew install php
then I believebrew upgrade
is enough to upgrade from 7.3 to latest 7.4.x
But if you are switching amongst PHP versions regularly, then using Valet to install the newest PHP version using valet use php@X.Y
will minimize Homebrew/Valet's confusion that can occur when just brew install php
happens (because in that case php
is "the latest PHP version at the time", and not symlinked to X.Y).
I just wondered if that process would create the issue itself.
As @shakil-muntasir just mentioned, it's the "start" command that's the issue, not the "install" command.
I'm always running the latest, so that's not a problem for me.
I'm pretty confident in this area now, so thank you to you both :)
Man, this continues to bite me all the time.
I think it happens after I run brew upgrade
. I upgrade, whatever misconfiguration that happens runs for several days, and then I get an alert from my computer when my disk is almost full.
Has anyone found a reliable solution for not getting bit by this?
I just upgraded from v2.15.3 => v2.16.1, so I suppose v2.15.2 wasn't the fix for me.
Is there some series of valet commands I should run when I run brew upgrade, in order to prevent this from happening?
I find that after doing brew upgrade, delete the plist files and then reinstall valet.
Clear description of your problem
An issue with Valet (inc latest version) causes PHP FPM to log the following messages every few seconds:
Over time, this log file can become huge e.g. tens of gigabytes. I have determined that when this happens, it is possible to fix the problem by deleting the sock file:
A single message is then logged (without repeating):
Expected behavior
The messages first mentioned in this issue should only be logged once, if at all. Valet still works either way.
Steps to Reproduce
Diagnosis
I'm running this after having fixed the problem as detailed above, so the details may not be relevant.
sw_vers
valet --version
cat ~/.config/valet/config.json
cat ~/.composer/composer.json
composer global diagnose
composer global outdated
ls -al /etc/sudoers.d/
brew config
brew services list
brew list --versions | grep -E "(php|nginx|dnsmasq|mariadb|mysql|mailhog|openssl)(@\d\..*)?\s"
brew outdated
php -v
which -a php
php --ini
nginx -v
curl --version
php --ri curl
~/.composer/vendor/laravel/valet/bin/ngrok version
ls -al ~/.ngrok2
brew info nginx
brew info php
brew info openssl
openssl version -a
openssl ciphers
sudo nginx -t
which -a php-fpm
/usr/local/opt/php/sbin/php-fpm -v
sudo /usr/local/opt/php/sbin/php-fpm -y /usr/local/etc/php/7.4/php-fpm.conf --test
ls -al ~/Library/LaunchAgents | grep homebrew
ls -al /Library/LaunchAgents | grep homebrew
ls -al /Library/LaunchDaemons | grep homebrew