➜ ~ brew services list
Name Status User Plist
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
[email protected] started ryan /Users/ryan/Library/LaunchAgents/[email protected]
nginx started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php error root /Library/LaunchDaemons/homebrew.mxcl.php.plist
redis started ryan /Users/ryan/Library/LaunchAgents/homebrew.mxcl.redis.plist
Not sure why but every time I run valet install my php service is in an error status. Manually running brew services restart php brings it up without error with a status of started.
Am I doing something wrong or is there a log file I can check or something?
You might get some details for troubleshooting with
sudo tail /usr/local/var/log/php-fpm.log
[10-Oct-2018 11:03:53] NOTICE: Terminating ...
[10-Oct-2018 11:03:53] NOTICE: exiting, bye-bye!
[10-Oct-2018 11:03:59] NOTICE: fpm is running, pid 5089
[10-Oct-2018 11:03:59] NOTICE: ready to handle connections
[10-Oct-2018 11:04:01] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[10-Oct-2018 11:04:01] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[10-Oct-2018 11:04:01] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[10-Oct-2018 11:04:01] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[10-Oct-2018 11:04:01] ERROR: An another FPM instance seems to already listen on /Users/ryan/.config/valet/valet.sock
[10-Oct-2018 11:04:01] ERROR: An another FPM instance seems to already listen on /Users/ryan/.config/valet/valet.sock
[10-Oct-2018 11:04:01] ERROR: FPM initialization failed
[10-Oct-2018 11:04:01] ERROR: FPM initialization failed
Solved.
It appears I had extra php services trying to start. I fixed with
brew services cleanup
and then
sudo brew services cleanup
I'm getting those logs every 10 seconds constantly while Valet is running, but they stop when I run valet stop:
[09-Jan-2019 10:55:00] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[09-Jan-2019 10:55:00] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[09-Jan-2019 10:55:00] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[09-Jan-2019 10:55:00] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[09-Jan-2019 10:55:00] ERROR: Another FPM instance seems to already listen on /Users/adambrown/.config/valet/valet.sock
[09-Jan-2019 10:55:00] ERROR: Another FPM instance seems to already listen on /Users/adambrown/.config/valet/valet.sock
[09-Jan-2019 10:55:00] ERROR: FPM initialization failed
[09-Jan-2019 10:55:00] ERROR: FPM initialization failed
However, when I run the cleanup commands, it doesn't help:
brew services cleanup
All user-space services OK, nothing cleaned...
sudo brew services cleanup
All root services OK, nothing cleaned...
The weird part is that Valet is working fine and serving sites, but the php-fpm.log file gets big in a hurry.
@ryanmortier were there any other steps you might have taken to stop those logs?
@iadambrown a few questions:
What PHP version?
Using your PHP version for X.X in the following: In your /usr/local/etc/php/X.X/php-fpm.d directory there are some *.conf files. Valet 2.1 normally makes edits to the www.conf file. But if you've got more files in there using the *.conf naming pattern then FPM will try to load those too. What's there?
What's your output from brew services list? It tells you what user services are running as.
Valet normally starts PHP-FPM as root, both with valet install and valet start, and on boot.
Have you done something to start it not as root? Was that intentional? Why?
@iadambrown my issue was only resolved until I brew updated again. This problem is back for me and I've just been dealing with it. I don't know why it's happening but at this point, I don't have the energy to figure it out so if you do solve it, please let me know.
I don't even know if those two commands are what fixed my problem initially either as I was trying all kinds of things. I pretty much uninstalled everything and reinstalled.
Here is my current log which as you can see is exhibiting the exact same behaviour:
[09-Jan-2019 12:05:10] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[09-Jan-2019 12:05:10] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[09-Jan-2019 12:05:10] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[09-Jan-2019 12:05:10] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[09-Jan-2019 12:05:10] ERROR: An another FPM instance seems to already listen on /Users/ryan/.config/valet/valet.sock
[09-Jan-2019 12:05:10] ERROR: An another FPM instance seems to already listen on /Users/ryan/.config/valet/valet.sock
[09-Jan-2019 12:05:10] ERROR: FPM initialization failed
[09-Jan-2019 12:05:10] ERROR: FPM initialization failed
My log file is 350MB lol...
@ryanmortier same questions:
Hi @drbyte, I'll need to switch back to PHP 7.3 get all the version details for you soon. I believe it was PHP 7.3.0 though, and Valet 2.1.5, both installed via Homebrew.
I've had to revert back to 7.2 to get Xdebug working properly again for work, so I'll need to get back with more details when I can try 7.3 again.
I haven't had a chance yet to see if the errors occur with the newly released PHP 7.3.1.
@ryanmortier same questions:
- php version
- brew services list -- what user are nginx and php running as?
- files in your php-fpm.d directory
Hi @drbyte ! I have the same issue.
~ php -v
PHP 7.1.25 (cli) (built: Dec 7 2018 08:20:45) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
with Xdebug v2.6.1, Copyright (c) 2002-2018, by Derick Rethans
with Zend OPcache v7.1.25, Copyright (c) 1999-2018, by Zend Technologies
~ brew services list
Name Status User Plist
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
mariadb started rumur /Users/rumur/Library/LaunchAgents/homebrew.mxcl.mariadb.plist
nginx started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
[email protected] started root /Library/LaunchDaemons/[email protected]
~ ls /usr/local/etc/php/7.1/php-fpm.d
www.conf
I fixed my issue last night by doing this:
brew uninstall phpbrew uninstall [email protected]brew uninstall [email protected]brew uninstall [email protected]brew cleanupbrew services cleanupsudo brew services cleanupbrew doctorbrew updatebrew install phpvalet installMy /usr/local/var/log/php-fpm.log doesn't get spammed with that junk anymore.
I haven't tried reinstalling the older versions of php though as I'm afraid the issue might come back. I'm currently running php 7.3.1
edit: I suspect the issue has something to do with having multiple versions of PHP installed with homebrew. Though simply having the services stopped didn't seem to matter, they needed to actually be uninstalled.
Valet 2.1.6 contains updates to the php-version detection, and plays better with Brew's new numbering scheme.
I was getting the 502 errors in the browser and FPM initialization failed and An another FPM instance seems to already listen on... errors in my php-fpm.log file. It turned out that large cookies/headers were causing the issue. I created a .conf file in my ~/.config/valet/Nginx/ and added the following lines and it fixed it for me.
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_read_timeout 180;
After that vulnerability in PHP-FPM a few days ago I had updated my php on a Catalina install and my fpm-php log blew up overnite with the exact errors above and crashed the computer (over 48GB log file, ran out of space). @ryanmortier - followed his steps, and now its working just fine!
brew services restart php
I am still seeing this issue. I am getting spammed frequently in my php-fpm.log. I assume brew/valet is conflicting with Mac's built in php version. I just can't figure out which the discrepancy is and how to stop this. It is cause gigantic backups and files.
I am still seeing this issue.
Which issue? There are 15 posts in this discussion. It would be much more helpful if you stated your exact symptoms, instead of saying a generic "me too".
I am getting spammed frequently in my php-fpm.log.
Spammed? Again, exact log content is always more useful than categorizing things using words of frustration.
I assume brew/valet is conflicting with Mac's built in php version.
Maybe. Maybe not. Can't tell without more details.
I just can't figure out which the discrepancy is
A good option to try might be to upgrade to the latest Valet version and run valet install in order to update things that might have old configurations, and then if it's still not working you could run valet uninstall --force to do an aggressive forced removal/cleanup. Then a reboot and a re-install of Valet.
I am extremely sorry. The issue I have been fighting with all day was the fact i was getting spammed in my php-fpm.log. I was getting spammed with
[08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:31] ERROR: FPM initialization failed
[08-Jan-2020 17:02:31] ERROR: FPM initialization failed
[08-Jan-2020 17:02:31] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:31] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:31] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:31] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:31] ERROR: FPM initialization failed
[08-Jan-2020 17:02:31] ERROR: FPM initialization failed
[08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:41] ERROR: FPM initialization failed
[08-Jan-2020 17:02:41] ERROR: FPM initialization failed
[08-Jan-2020 17:02:41] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:41] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:41] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:41] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root
[08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock
[08-Jan-2020 17:02:41] ERROR: FPM initialization failed
[08-Jan-2020 17:02:41] ERROR: FPM initialization failed
But I couldn't understand why these kept popping up even after i uninstalled all versions of php and ran all the code @ryanmortier posted.
I dug a little deeper and noticed I had erroneous launch agents which were never removed by brew in
~/Library/LaunchAgents/
/Library/LaunchAgents
I uninstalled all versions of PHP from brew and then deleted out all the launchagents that still existed. I then reinstalled default php via brew and did a valet install. It seems to be behaving properly.
I dug a little deeper and noticed I had erroneous launch agents which were never removed by brew in
~/Library/LaunchAgents/
/Library/LaunchAgentsI uninstalled all versions of PHP from brew and then deleted out all the launchagents that still existed. I then reinstalled default php via brew and did a valet install. It seems to be behaving properly.
Yes, in the rare case that those LaunchAgents have been orphaned, that's the best way to clean it up. (Sometimes LaunchDaemons too.)
Glad you got it sorted out!
I am extremely sorry. The issue I have been fighting with all day was the fact i was getting spammed in my php-fpm.log. I was getting spammed with
[08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:31] ERROR: FPM initialization failed [08-Jan-2020 17:02:31] ERROR: FPM initialization failed [08-Jan-2020 17:02:31] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:31] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:31] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:31] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:31] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:31] ERROR: FPM initialization failed [08-Jan-2020 17:02:31] ERROR: FPM initialization failed [08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:41] ERROR: FPM initialization failed [08-Jan-2020 17:02:41] ERROR: FPM initialization failed [08-Jan-2020 17:02:41] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:41] NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:41] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:41] NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root [08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:41] ERROR: Another FPM instance seems to already listen on /Users/joe/.config/valet/valet.sock [08-Jan-2020 17:02:41] ERROR: FPM initialization failed [08-Jan-2020 17:02:41] ERROR: FPM initialization failedBut I couldn't understand why these kept popping up even after i uninstalled all versions of php and ran all the code @ryanmortier posted.
I dug a little deeper and noticed I had erroneous launch agents which were never removed by brew in
~/Library/LaunchAgents/
/Library/LaunchAgentsI uninstalled all versions of PHP from brew and then deleted out all the launchagents that still existed. I then reinstalled default php via brew and did a valet install. It seems to be behaving properly.
brew services restart php
Odd, I did
brew services stop php
brew services list
I noticed that after stopping it, it now said that php was started, when before it said there was an error.
When I tried to stop it again it says:
Error: Service
phpis started asroot. Try:
sudo brew services stop php"
It seems to be running fine under root, but it seems that there was also a user service competing against the root service :\ so odd...
Now my log file is not growing constantly :) (hopefully this holds up for a reboot or valet restart.
Now I no longer see the php mxcl plist file in the ~/Library/LaunchAgents either.
Most helpful comment
I fixed my issue last night by doing this:
brew uninstall phpbrew uninstall [email protected]brew uninstall [email protected]brew uninstall [email protected]brew cleanupbrew services cleanupsudo brew services cleanupbrew doctorbrew updatebrew install phpvalet installMy
/usr/local/var/log/php-fpm.logdoesn't get spammed with that junk anymore.I haven't tried reinstalling the older versions of php though as I'm afraid the issue might come back. I'm currently running php 7.3.1
edit: I suspect the issue has something to do with having multiple versions of PHP installed with homebrew. Though simply having the services stopped didn't seem to matter, they needed to actually be uninstalled.