Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fresh installation of Valet not working on CMS backends #791
Ive been trying several times to get Laravel completely working ()MBP 2018, Mojave 10.14.5). Below are the steps and caveat messages during installation. No errors were reported.
Valet link & securing a site
Link and certificate created. Frontend of CMS (Statamic) works fine with https.
/usr/local/var/log/nginx/access.log – empty
Restarting services and Valet
Restarting services with sudo
After serveral reloads, the backend login screen appears and I can log in. When I click on a CP link to get a list of available updates from the CMS server, I get the bad gateway again and that page is not loaded.
This attempt was with Statamic CMS, but I tried with Craft CMS as well – every time a license key or versions are checked, Craft CP gives an error, plugin store can not be reached within admin.
In Laravel Valet on Discord the same or very similar problems are reported for Wordpress. Trying firstname.lastname@example.org and email@example.com did not solve the problem, also not starting all over by removing and reinstalling Homebrew and installing only one of those versions.
Thanks for reading this far and for your suggestions :)
I didn't see mention of a reboot. Do that first, as it cleans up previously-configured running instances of things that could conflict. 95% of the time that fixes everything.
Your dnsmasq is working fine, else it wouldn't give you any webpages when visiting .test domains.
The "502 Bad Gateway" is always a message from Nginx saying that PHP-FPM couldn't proxy through the gateway socket to a running PHP-FPM instance.
The "Another FPM instances ... already listen on ... valet.sock" message suggests there are multiple FPM configs enabled in your PHP. Or something's configured to start another copy of the same FPM instance.
Valet has very simple requirements: a couple custom settings to point to the valet-managed server definitions.
What's in your
Hello Chris, thank you very much for the very fast reply! Here the feedback on the list of things to check:
The complete usr/local/etc/php directory is
(There is no
Sorry for the confusion about the
Forgot: I rebooted, but no different behavior.
Another edit: Where should the socket file live and when: Should it exist even with the nginx errors?
Finder probably won't show it. But you can use
None of the Valet sites will serve any PHP if the valet.sock isn't present.
For giggles, I tried installing CraftCMS, first time.
cd ~/Sites composer create-project craftcms/craft craftcms cd craftcms craft setup # (answered questions, to provide database, gave url of craftcms.test to match valet) valet open
... so it appears that the basic Valet setup works fine for CMS backends.
I am also facing this issue on mac with latest valet. I am trying to call an API using Guzzle Http lib and it gives me 502 bad gateway error.
After researching and spending a lot of time, I found this Stock Overflow answer
The problem is that php is not running as root. I checked by
So some time, my API call works because of the php-fpm process running as root .
I tried to run php as root by making changes in www.conf file, but does not work and gives error as
Hi Chris, congratulations on the successful Craft installation :) I completely removed Valet & Composer in
As I understand from the logs, the first error is thrown because Craft can't verify the license, and the second because it can not load the plugin store. For me, the problem does not relate to Craft, since Statamic is having the same gateway problem as well (when I try to connect to the updates server from the CP). I'm having a hard time to believe, it´s due to an exotic install on my Mac, since others are reporting the issues as well for WP (on Laravel/Valet Discord). And my Valet was working well for Craft and Statamic well over a year.
What has blown the setup up I think was
I think it is very likely the problem does not lie within Valet, maybe something in Homebrew or PHP formulaes has changed and Valet thinks it is restarting processes with root but can't? Altaf Hussain reports that several php-fpm processes are running as user, and I have exactly the same, see here:
Restarting php with
One thing you could try ... The latest homebrew php seems to be adding some cacert defaults in php.ini that weren’t there in prior versions. At/near the bottom of php.ini comment out (with semicolon) those two values. Then restart php. Those affect the ssl negotiation that may be giving guzzle trouble. Just a thought. (And only temporary, as I wouldn't normally suggest editing those.)
Thank you for the suggestions, I did try them, sudo restarted PGP and NGINX and ran ' valet install`and rebooted. No breakthrough. I had hopes cause at one time I needed only two reloads to make the "Updates" page in Statamic CP show up, but the next time I had to didi approx. 20 reloads to make this happen. And once in all the tries fro Craft CMS, I had no Error after login, but the Plugin Store would never appear. So it does not fail 100%, but almost every time. Probably it is like Althaf Hussain writes: Sometimes we are lucky and the root php-fpm is used, most of the time it does not work because a user php-fpm is loaded.
One thing I've been exploring is setting up a separate FPM config specific to Valet, so that the default can be left alone.
It's pretty much the same as I posted previously when investigating things, except at the top of this one the process name is
You'd need to rename your (now customized by valet's install) www.conf in that same directory to something NOT ending in
As to "running as root" vs as the user, while I've read that report, I'm unconvinced yet.
Homebrew is indeed starting the PHP service as root, and then the individual web processes that fire up to run requested PHP instances for webpages run as the user in order to have proper permissions to access the files. This is standard practice for nginx/php-fpm operation. That's why it gave you errors when you tried to tell it to do otherwise.
I'd rather have you get your failing application to "log" exactly what's failing and why. Get guzzle to say what the error is. That may mean you need to hack at the code in the app's vendor directory and enable debugging (or override catching the exceptions without reporting their cause).
@drbyte the issue does not seem in Guzzle. The issue is in PHP
As I was not able to run php-fpm as root from www.conf by making
As valet is used for local development so i think there is no issue with running php-fpm as root as same is done by homebrew.
Okay, where EXACTLY is the issue then?
Running as root is just a bandage in my opinion, and not an actual "solution". Let's understand what exactly is triggering the segfault, and then that will expose a clearer path to the right solution.
Alright: give me a short simple code sample that can be used to recreate this segfault.
There seems to be no 'code' in any one application that causes this error as it shows different results depending on the application.
I've got a Laravel build that curl's an API and then with that data insert it into the database, but once ran it crashes and presents the error: "Segmentation fault: 11"
However the logs are clear, this error started occurring at the same as with the 502 WordPress error when navigating to the backend of the site.
This leads me to believe it could be a mix of PHP & MySQL.
While I still believe merely letting PHP-FPM "run as root" is going to short-circuit finding the "real" solution, you can do that by modifying the startup parameters of fpm:
<string>--nodaemonize</string> + <string>--allow-to-run-as-root</string>
(and then change your fpm conf.d file "user" entry to "root", and
I think it'd be possibly more helpful to instead add the following to ask it to log more "extended details" when problems occur:
<string>--nodaemonize</string> + <string>-e</string>
Additionally, running FPM manually from the command line and passing the URL of a page in your project which triggers the segfault could reveal more details about the actual cause:
And then run the following, substituting YOURUSERNAME and PROJECTNAME appropriately. You might need to update the URI and Query string to suit as well. Basically this is running your app from command-line, encouraging it to output more details:
SCRIPT_FILENAME=/Users/YOURUSERNAME/Sites/PROJECTNAME/public/index.php \ REQUEST_URI=/ \ QUERY_STRING=/ \ REQUEST_METHOD=GET \ /usr/local/bin/cgi-fcgi -bind -connect /Users/YOURUSERNAME/.config/valet/valet.sock
After giving it the 'bandage' you suggested, it took longer to load the page as it looked to be 'thinking' about it.
It first gave me this error:
Tweaked the user profile bit and no it changed back to:
As for the Laravel code command, I'm stilling getting:
Please follow the links for the fix: