-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP FPM Service Failing to Start #1334
Comments
We're seeing this same behavior on 7.1.33-9+ubuntu16.04.1+deb.sury.org+1. Going back to 7.1.33-8+ubuntu16.04.1+deb.sury.org+2 works fine. Thanks for your work on this! |
What’s the output of |
same issue as @joelbeckham above with
|
For me it looks like: systemctl status php7.2-fpm:
journalctl -u php7.2-fpm
|
Of note If it helps, here's the output of
The FPM log looks like this, nothing of interest:
The FPM error log file is empty. I can run the other PHP provisioners if it helps, but I'm unsure if they'll give much useful information.
|
What’s pidfile settings in php-fpm.conf after provisioning? |
These might be two distinct errors. For 7.2 it sort of looks like the failed ExecStopPost fails the whole unit and for 7.1 it looks like missing pidfile. |
This is the problem: |
Dup of #1333 |
@joelbeckham @automationforthepeople looks like it’s the same issue in the end. If you want mangle defaults, put an override for the unit. P.S.: no systemd hate speech please, the sysvrc script would have the same problem if it was checking the pidfile in default location. |
@oerdnj I destroyed my VM, commented the pid line out, reprovisioned, the service still fails to start, I see no change. As for starting the services, the line is Adding to this, that line with the pid file value was set 6 years ago, and we've just updated the PHP version, I'm unsure why if it's incorrect it would stop working with the release of updated packages, old versions of VVV from a year ago no longer work and the only thing that's changed are that packages installed via The service fails in the same way as before, with the |
So, what is the log output when the line is removed? |
Of note, that sock file doesn't exist, but, |
Now, I am at computer again (not at phone). If you look at the default php-fpm.conf, it says:
So, if you comment out the line, it won't work, you either need to set it to the previous correct value, or disable it completely (systemd unit override with The |
@oerdnj thanks, I've started distributing the fix, do you know caused the change? We've had it set up this way since 2014 but it's only in the last week it's needed this fix, was there a change in the way the package installs itself? |
Experiencing the same issue on servers managed by salt-stack. The issue is even now that I figured out how to fix the config to set the As a workaround I am now bringing every machine out of rotation one by one and doing: |
I built a server recently, and another one yesterday. Identical provisioning scripts, but yesterday's server didn't run, with the issue in the thread. Comparing the two I found:
Rather than change the systemd service file, it looks like the distributed |
@pbowyer The problem here is that the package is correct as far as I can see:
So, the invalid pid path comes from somewhere else. The only thing that I don't know is why the problem started manifesting after adding
|
Same with the 18.04:
@pbowyer: ^^^ |
@oerdnj Yes, the file in the package is right. The puppet module that installs my PHP was responsible for changing the pid path to I see @tomjn has made a similar change to the VVV project (which uses shell scripts rather than puppet). But they too have been copying their own Is it possible that the php-fpm package used to install its config file later than it does now - over the top of the edited one made/installed by the deployment script. Do you know if anything changed (at an operating system level, maybe?) that would mean the php-fpm package installs its config file earlier than it did before? |
I hit this bug today when upgrading php7.3-fpm from We customize the path to the PID file in the php-fpm.conf, so we ended up fixing it by overriding the |
The PID file location for Debian changed recently see https://www.patreon.com/posts/february-updates-34189046 and oerdnj/deb.sury.org#1334
See oerdnj/deb.sury.org#1334 Uses /run/php/phpx.x-fpm.pid (in directory /run/php)
See oerdnj/deb.sury.org#1334 Uses /run/php/phpx.x-fpm.pid (in directory /run/php)
* Rework php-fpm.conf per changes in debsury See oerdnj/deb.sury.org#1334 Uses /run/php/phpx.x-fpm.pid (in directory /run/php) * Improve TestExtraPackages to use php-gmp and clean up
…ev#2099) * Rework php-fpm.conf per changes in debsury See oerdnj/deb.sury.org#1334 Uses /run/php/phpx.x-fpm.pid (in directory /run/php) * Improve TestExtraPackages to use php-gmp and clean up
I encountered the same issue when upgrading to Our Ansible template for
The
But the I tried changing the default value for the PID file like so:
to avoid any issues with the parsing, but this still does not work. Changing the PID file path in the It's not a massive problem, but the current setup is working on servers with |
Unsupported distributions
Repository mirroring
Describe the bug
This appears to be very similar to #1327, however, I'm using the package versions that were supposed to fix the issue. Starting the FPM services fails with a timeout, in my particular case I see similar results to #1327
Of note, PHP 5.6/7/7.1/7.2/7.3/7.4 FPM are all failing while attempting to provision VVV on 18.04, across multiple versions of VVV, so changes in VVV can be ruled out as versions that were released a year ago are also impacted.
To Reproduce
In this case, cloning the VVV project and running
vagrant up
will reproduce the issue. We have dedicated PHP provisioner scripts for each version of PHP if that helps, but a `sudo apt-get install php7.2-fpmOn an already provisioned VM, I tried to run
sudo apt-get install php7.2-fpm --reinstall
, this was the result:Expected behavior
I expected PHP FPM to install and startup up when commanded to
Distribution (please complete the following information):
Apt sources:
Package(s) (please complete the following information):
Full list of packages the provisioner installs:
https://github.com/Varying-Vagrant-Vagrants/VVV/blob/develop/provision/provision.sh#L140-L220
Output of
apt-cache policy <package>
works best.Additional context
We're really thankful for all the work that goes into this, if you need any assistance or additional information please let me know
The text was updated successfully, but these errors were encountered: