VVV: PHP FPM Service timeout, leading to Gateway 502

For specifics, the issue was the process ID file that PHP FPM uses to start itself up with. Fixing it involved changing it back to the default.

I’m still unsure why it was needed now yet it worked fine for 6 years though. I’ve asked Ondrej in the GH issue but I imagine he has more important things to wrangle.

For people not using the latest VVV, you’ll get the fix for other PHP versions, but your mileage with the default version may vary. I’d recommend updating. A git pull and a reprovision should be enough for most people, you don’t have to destroy the VM.

master and v3.3

As for master, it now contains the unreleased v3.3, at some point over the next few days it’ll have its changelog updated from the PRs and commits, and we’ll tag it, otherwise you’ll get mostly bug fixes, e.g. mailhog working on CLI, small performance boosts, and several unhandled issues being handled. The biggest changes that have happened in the last 6 months have been in the utility repo, which VVV pulls down regardless of version anyway

you deserve a ☕️ !

I’m at WC Glasgow this weekend, and should be around at europe 😃 If anybody would like to join the tester program let me know, it just means every now and again you’ll change to a PR branch, reprovision, and double check everything still works

We’re around on the VVV slack too https://varyingvagrantvagrants.org/docs/en-US/slack/

I’m going to leave this issue open for a few days, I’m a little concerned that @gregsullivan had to destroy their VM, if you end up in that situation let me know via slack

@bigmike7801 ssh into the box:

sudo apt-get --purge remove php7.2-fpm
sudo apt-get --reinstall install php7.2-fpm

Then restart your box and provision

If I run vagrant up the FPM service doesn’t start, leading to the 502 errors.

However, if I SSH into the VM and run sudo php-fpm7.2, the dashboard loads again and sites begin to work

I pulled down the latest develop branch and tried after vagrant halt and vagrant up --provision, but to no avail.

It worked after vagrant destroy.

Edit: While it’s too late for me to test, I’d suggest trying @vertizio’s solution below before running vagrant destroy.

Temporary solution for me was to change from using a socket file to a port (I used 9000)

Modify /etc/php/7.2/fpm/pool.d/www.conf: Change line 33 to listen = 127.0.0.1:9000

Modify /lib/systemd/system/php7.2-fpm.service and remove the 2 lines which talk about adding/removing sockets

Modify /etc/nginx/nginx.conf Change line 90 to server 127.0.0.1:9000;

sudo systemctl daemon-reload

sudo service php7.2-fpm restart sudo service nginx restart

This is a temp fix until it’s fixed properly I guess, but at least I can continue development…

The fix is on both develop and master, and it’s in the core utility. A reprovision will be needed for the fix to take effect.

Note that on older versions of VVV, the config file may not get updated, newer versions of VVV force copy the PHP config files

It looks like this is a problem upstream with the PHP packages, there were issues very recently, unsure why we’re still encountering them though as they’re meant to have been resolved

I’ve opened https://github.com/oerdnj/deb.sury.org/issues/1334 to try and provide more details and get to the bottom of this

I’m seeing this on master branch as well.

@vertizio That did the trick!