Closed marflow closed 4 years ago
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.
502 Bad Gateway
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.
PHP-FPM configured as the main user, and registered to listen on the valet.sock file. In valet v2 this is done in the /usr/local/etc/php/7.3/php-fpm.d/www.conf
file by customizing the following settings:
[www]
user = yourusername
group = staff
listen = "/Users/yourusername/.config/valet/valet.sock"
listen.owner = yourusername
listen.group = staff
listen.mode = 0777
Are there other *.conf
files in that same dir? If so, what's in them? Why are they there? A standard Valet v2 install doesn't have any other .conf files there. (PHP puts a .conf.default file there, but that's just a sample, not ending in .conf)
Then nginx is configured to point to your valet configs:
What's in your: /usr/local/etc/nginx/nginx.conf
?
By default valet v2 makes it akin to:
user "yourusername" staff;
worker_processes auto;
events { worker_connections 1024; }
http { include mime.types; default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
client_max_body_size 128M;
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
ssi on;
gzip_types
application/atom+xml
application/javascript
application/json
application/rss+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/svg+xml
image/x-icon
text/css
text/plain
text/x-component;
include "/Users/yourusername/.config/valet/Nginx/*";
include servers/*;
include valet/valet.conf;
}
4. What's in your `/usr/local/etc/nginx/valet/valet.conf`?
By default Valet v2 makes it something like:
server { listen 80 default_server; root /; charset utf-8; client_max_body_size 128M;
location /41c270e4-5535-4daa-b23e-c269744c2f45/ {
internal;
alias /;
try_files $uri $uri/;
}
location / {
rewrite ^ "/Users/yourusername/.composer/vendor/laravel/valet/server.php" last;
}
access_log off;
error_log "/Users/yourusername/.config/valet/Log/nginx-error.log";
error_page 404 "/Users/yourusername/.composer/vendor/laravel/valet/server.php";
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass "unix:/Users/yourusername/.config/valet/valet.sock";
fastcgi_index "/Users/yourusername/.composer/vendor/laravel/valet/server.php";
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME "/Users/yourusername/.composer/vendor/laravel/valet/server.php";
}
location ~ /\.ht {
deny all;
}
}
What's in your `~/.config/valet/Nginx` directory?
> ~/sites/.config/valet/Log/nginx-error.log:
Is that `/sites/` subdir really part of the path? If so, then you've made a huge alteration that means you'll need to troubleshoot all the changes on your own.
Hello Chris, thank you very much for the very fast reply! Here the feedback on the list of things to check:
www.conf
is the only .conf file in /usr/local/etc/php/7.3/php-fpm.d/www.conf
. Settings exactly like you wrote with my username inserted. The only other things not commented out in the file:
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
The complete usr/local/etc/php directory is
php
conf.d
- ext-opcache.ini
- php-memory-limits.ini
php-fpm.d
- www.conf
- pear.conf
- php-fpm.conf
- php.ini
(There is no php.conf.default
)
/usr/local/etc/nginx/nginx.conf
is exactly like you posted, only difference my username.
/usr/local/etc/nginx/valet/valet.conf
is exactly like your example with my username.
Sorry for the confusion about the /sites/
segment, my mistake, it is not in the path, everything is standard (or I would like it to be ;)
Path is ~/.config/valet/Nginx
and momentarily there are tow files in there : .keep
and a file mysite.test
for the one site I linked and secured. Should I past the contents of that file or look for something?
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?
The ~/.config/valet/valet.sock
file only exists when PHP-FPM is running and using the Valet configuration.
Just so I'm clear, for you Valet runs fine for basic site access, just not for certain control-panel screens?
So I should see valet.sock
in col 3 when I load the site in the browser (nothing there).
Yes, right. I can see everything that does not need a gateway. I guess an iframe on the front-end should cause an error, too.
I´ve read here that some people did tweak the children and server settings in www.conf
and someone placed a .conf
file with increased buffer sizes somewhere in the ~/.config/valet/
, but that did not change anything for me.
Could Valet somehow get linked to the wrong www.conf
? I have found these three:
So I should see valet.sockin col 3 when I load the site in the browser (nothing there).
Finder probably won't show it. But you can use ls
on the command line to see it. ls -al ~/.config/valet
None of the Valet sites will serve any PHP if the valet.sock isn't present.
Could Valet somehow get linked to the wrong www.conf? Only if you've customized your
~/.config/valet/Nginx/*.test
files to use a different socket or PHP-FPM connection.
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
Craft window appeared in browser:
Clicked to open Control Panel:
... so it appears that the basic Valet setup works fine for CMS backends.
Perhaps for your situation it's worth enabling some additional nginx logging to figure out what URL it's trying to hit when the 502 Bad Gateway is being triggered, in order to understand more of what's going on in the background, unique to your environment.
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 ps aux | grep php-fpm
and two processes are running as my username and one process as root (I am not sure how on my mac) as can be seen in screenshot
So some time, my API call works because of the php-fpm process running as root . According to the answer in above link, if php run as root, then this issue can be fixed.
I tried to run php as root by making changes in www.conf file, but does not work and gives error as pool www] please specify user and group other than root
. I am not sure how valet config can be modified to start php-fpm as root. Any details provided will help a lot.
Hi Chris, congratulations on the successful Craft installation :) I completely removed Valet & Composer in usr
and ~/
folders, PHP, NGINX, NDSMASQ, MySQL, Homebrew again and reinstalled Mojave, front-end is fine as before and backend looks like this:
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 Brew upgrade
and brew update
prior to a Laravel-Mix installation. Since then I spent a week trying to get things running smoothly again, with many complete reinstalls starting from Homebrew with different PHP versions, then installing several PHP versions and changing them with are link --force
, valet use …
, I did restores from Time Machine and I did also set up the Mac completely fresh by wiping the disk and re-installing Mojave.
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 sudo
does not solve it, the user processes are always coming back. If that could be fixed dirty on our end, it would be great. My knowledge is not enough to investigate the issue.
However: Thanks a lot for your time and effort you put into the trouble shooting, especially on the weekend, much appreciated!
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.
Thanks again!
One thing I've been exploring is setting up a separate FPM config specific to Valet, so that the default can be left alone.
Doing that requires creating a new file:
/usr/local/etc/php/7.3/php-fpm.d/valet-fpm.conf
with content:
[valet]
user = YOURUSERNAME
group = staff
listen = "/Users/YOURUSERNAME/.config/valet/valet.sock"
listen.owner = YOURUSERNAME
listen.group = staff
listen.mode = 0777
php_admin_value[memory_limit] = 128M
php_admin_value[upload_max_filesize] = 128M
php_admin_value[post_max_size] = 128M
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
It's pretty much the same as I posted previously when investigating things, except at the top of this one the process name is [valet]
instead of [www]
.
You'd need to rename your (now customized by valet's install) www.conf in that same directory to something NOT ending in .conf
.
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). Somewhere in there is the key to the solution.
@drbyte the issue does not seem in Guzzle. The issue is in PHP SIGSEGV
as can be seen in screenshot.
As I was not able to run php-fpm as root from www.conf by making user = root
. But as random guess, what I did was kept the user = myusername
and changed the listen.owner
user to root
but the issue is still not fixed.
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.
@drbyte the issue does not seem in Guzzle.
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.
The issue is in PHP
SIGSEGV
as can be seen in screenshot.
Alright: give me a short simple code sample that can be used to recreate this segfault. Then we can use that for testing and investigation.
@drbyte the issue does not seem in Guzzle.
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.
The issue is in PHP
SIGSEGV
as can be seen in screenshot.Alright: give me a short simple code sample that can be used to recreate this segfault. Then we can use that for testing and investigation.
Hi @drbyte,
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"
The code: https://gist.github.com/da-mreale/04941d6a0a41d3b8b31b338dd4a4b45f
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:
/usr/local/Cellar/php/7.3.6_1/homebrew.mxcl.php.plist
<string>--nodaemonize</string>
+ <string>--allow-to-run-as-root</string>
(and then change your fpm conf.d file "user" entry to "root", and valet restart
)
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:
brew install fcgi
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:
2019/07/02 14:08:53 [error] 19171#0: *1 FastCGI sent in stderr: "PHP message: PHP Warning: require(/Volumes/Samsung SSD/Dev Sites/extranet/index.php): failed to open stream: Operation not permitted in /Users/matt/.composer/vendor/laravel/valet/server.php on line 158PHP message: PHP Fatal error: require(): Failed opening required '/Volumes/Samsung SSD/Dev Sites/extranet/index.php' (include_path='.:/usr/local/Cellar/php/7.3.6_1/share/php/pear') in /Users/matt/.composer/vendor/laravel/valet/server.php on line 158" while reading response header from upstream, client: 127.0.0.1, server: extranet.test, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/Users/matt/.config/valet/valet.sock:", host: "extranet.test"
Tweaked the user profile bit and no it changed back to:
2019/07/02 14:20:07 [error] 21375#0: *95 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: extranet.test, request: "GET /wp-admin/post.php?post=7&action=edit HTTP/2.0", upstream: "fastcgi://unix:/Users/matt/.config/valet/valet.sock:", host: "extranet.test", referrer: "https://extranet.test/"
As for the Laravel code command, I'm stilling getting:
Matthews-MacBook-Pro:demo-code matt$ php artisan test:sync Test 1 - Free trial registration checker. Connecting to Fisikal API... Connected to the Fisikal API. Updating client count... Segmentation fault: 11 Matthews-MacBook-Pro:demo-code matt$
I have been receiving the 502 Bad Gateway since updated to 'MacOS mojave 10.14.5". I don't receive the 502 error for each request, but it frequent. For Guzzle, the failure rate is very high.
@marflow, @drbyte I think, I have found the issue for the 502 errors. The recent version of curl-openssl is throwing "Segmentation fault" error which is causing the 502 Nginx error.
Please follow the links for the fix: https://discourse.brew.sh/t/symfony-4-segmentaion-fault-11/5074/13 https://github.com/Homebrew/homebrew-core/issues/40812
Thanks for the info and link, @anam-hossain! Hope you can sort out your problems now. As I could not get my set up to function well, I´ve switched to Homestead yesterday. That´s working for me.
@marflow if this is no longer an issue for you, do you mind closing it? Thanks!
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. If a Valet expert would know where the problem lies, help would be very appreciated.
Homebrew
PHP
Composer
Valet
Checking
Valet link & securing a site
Link and certificate created. Frontend of CMS (Statamic) works fine with https. Trying to login into CP gives me
~/sites/.config/valet/Log/nginx-error.log:
/usr/local/var/log/php-fpm.log:
/usr/local/var/log/nginx/access.log – empty /usr/local/var/log/nginx/error.log – empty
Restarting services and Valet
/usr/local/var/log/php-fpm.log:
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 php@7.2 and php@7.1 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 :)