I get an error in the Start php7.1-fpm service
task, when I try to reprovision (running vagrant provision
) my development setup with the latest trellis git version:
Unable to start service php7.1-fpm: Job for php7.1-fpm.service failed because the control process exited with error code.
I guess it’s because the service is already running. Anything I could do about this?
That shouldn’t be causing an error on its own.
You can try to start it manually and see what the error is.
vagrant ssh
sudo service php7.1-fpm stop
sudo service php7.1-fpm start
Hopefully it has a helpful error message
That actually gives me the same error.
In systemctl status php7.1-fpm.service
it says:
ERROR: An another FPM instance seems to already listen on /var/run/php-fpm-wordpress.sock
So what does this mean? I actually get this error also after restarting vagrant and running systemctl status php7.1-fpm
. But the service seems to run nevertheless.
I ended up applying this very old workaround described here:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1242376
and it actually worked.
I still don’t understand this, because this bug was for running php5-fpm with upstart, which is not used anymore in 16.04, I think.
But I always have this problem when reprovisioning the dev server and uncommenting reload signal USR2
in /etc/init/php7.1-fpm.conf
does seem to help.
@swalkinshaw: You can not reproduce this, do you?
I’ve had issues with the php reload task after updating Trellis and/or Ansible locally (I’m not sure which thing broke it, I did them both at the same time). Destroying and reprovisioning the server (both the vagrant local vm and my staging and production servers) resolved it. I assume it’s a difference between the versions of software originally deployed and those the latest version of Trellis wants to use. That’s a wild guess, though.
I’ve never had this issue (or any time recently). But I’d be concerned if it happened on a brand new install/box.
Was just a trellis update in my case (I think).
OK, I didn’t want to go that far. But in the end it might be easier.
I’ll can try with a fresh install. But I had this issue with a server here that I reprovisioned to the current version, where I simply ran vagrant provision
again as a test. No big deal, just found it a bit strange.
With a database and uploads backup you should be able to turn around a destroy/provision/deploy in about 10 minutes. And then if it works you’re done.
That’s right, I’m still a bit too hesitant to destroy and recreate the complete server, but it’s probably more reasonable.
Good practice, too. One of the great benefits of Trellis is how disposable the server can be.