504 Gateway timeout

[claystation]

Hello,

I am trying to get Valet working on my new Mac Mojave 10.14.3.

I installed PHP 7.2 through Homebrew (As 7.3 is having difficulties with xDebug).
I linked it and added it to the path.

php -v

PHP 7.2.15 (cli) (built: Feb  7 2019 20:10:03) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Xdebug v2.6.1, Copyright (c) 2002-2018, by Derick Rethans
    with Zend OPcache v7.2.15, Copyright (c) 1999-2018, by Zend Technologies

Installing valet with valet install

Stopping nginx...
Installing nginx...
[nginx] is not installed, installing it now via Brew... 🍻
Installing nginx configuration...
Installing nginx directory...
Updating PHP configuration...
Restarting php@7.2...
Installing dnsmasq...
[dnsmasq] is not installed, installing it now via Brew... 🍻
Restarting dnsmasq...
Valet is configured to serve for TLD [.test]
Restarting nginx...

Valet installed successfully!

I linked my project:

+--------------+-----+--------------------------+-----------------------------------------------------+
| Site         | SSL | URL                      | Path                                                |
+--------------+-----+--------------------------+-----------------------------------------------------+
| application |     | http://application.test | /Users/claystation/development/laravel/application |
+--------------+-----+--------------------------+-----------------------------------------------------+

But visiting https://application.test gives me a Gateway timeout. It was working before a reboot (after a lot of fiddling with every aspect (brew/valet/php). I do not want to have the common solution of raising timeout limits. Because that can never be a problem for loading a simple laravel app on my local computer. I have no clue where to look else or what to do. I tried reinstall everything. (Php by my self and nginx/dnsmasq through valet install). I am new to OSX so, if i am missing something obvious, please forgive me.

Some extra information:

brew services list

Name    Status  User    Plist
dnsmasq started root    /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
mariadb started claystation /Users/claystation/Library/LaunchAgents/homebrew.mxcl.mariadb.plist
nginx   started root    /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php@7.2 started root    /Library/LaunchDaemons/homebrew.mxcl.php@7.2.plist

cat ~/.config/valet/Log/nginx-error.log

2019/02/13 10:51:22 [error] 56174#0: *1 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/Users/claystation/.config/valet/valet.sock", host: "application.test"

cat /usr/local/var/log/php-fpm.log

[13-Feb-2019 10:49:57] NOTICE: fpm is running, pid 54208
[13-Feb-2019 10:49:57] NOTICE: ready to handle connections

ps aux | grep fpm

claystation          54225   0.0  0.0  4524688   1184   ??  S    10:49AM   0:00.00 /usr/local/opt/php@7.2/sbin/php-fpm --nodaemonize
claystation          54224   0.0  0.2  4541536  28204   ??  S    10:49AM   0:00.32 /usr/local/opt/php@7.2/sbin/php-fpm --nodaemonize
root                 54208   0.0  0.1  4524688  15176   ??  Ss   10:49AM   0:00.07 /usr/local/opt/php@7.2/sbin/php-fpm --nodaemonize
claystation          56833   0.0  0.0  4268060    820 s004  S+   11:02AM   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn fpm

[drbyte]

Your diagnostic steps are good. and you're right that you shouldn't need to set some massive timeout. That's because the timeout problem isn't that a script is taking too long; it's because PHP isn't responding at all.

You can confirm this with your nginx-error.log which shows the "upstream timed out" and mentions the socket it's listening on.
(And by the way, it's quoting the proper socket path, so that means nginx is apparently properly configured, at least for the FPM part.)

Does /Users/claystation/.config/valet/valet.sock exist?
If not, then either PHP isn't configured for it (valet install should have done that by setting the listen path), or the configured PHP service isn't running (your brew services list properly shows it as running and as root).

[claystation]

Yes the valet.sock exists. And the PHP process is running as verified by brew services list and by ps aux | grep fpm right? What other steps can i take? Should php not run as root? Because when i install through brew install php@7.2 this is the outcome.

[drbyte]

What are the user and group and listen settings set to in your php.ini, for the running PHP version?
See /usr/local/etc/php
If the listen param isn't set to the valet.sock path then it won't work. valet install should have set those 3 values according to its own rules.

[claystation]

I can not find such settings in the php.ini but i found them in the /usr/local/etc/php/7.2/php-fpm.d/www.conf. Verified by php -i that i am using the php.ini from the same path (/usr/local/etc/php/7.2/php.ini)

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = claystation
group = staff

; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific IPv4 address on
;                            a specific port;
;   '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6 address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses
;                            (IPv6 and IPv4-mapped) on a specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = /Users/claystation/.config/valet/valet.sock

[claystation]

After a random reboot, Valet started working again? I have no clue on how to pinpoint the problem now. All i can say: a reboot fixed it for me. Sorry about that.

[chinleung]

After a random reboot, Valet started working again? I have no clue on how to pinpoint the problem now. All i can say: a reboot fixed it for me. Sorry about that.

I had the same issue and it worked for me after a reboot as well. 🤔

[piperhaywood]

Just third-ing this, same here. Reboot was the only thing that sorted it. Who knows why!

[renepardon]

Fixed it also for me - a random restart ;(

[bingalls]

I ran into this problem, when using brew-php-switcher. Run brew services list and change php to php@7.4 for example (replace with your actual version)