Open jessuppi opened 1 year ago
Strangely it seems like it was a common error before when using Plesk:
Ref: https://talk.plesk.com/threads/plesk-php-7-3-fpm-service-failed-to-start.358336/ Ref: https://bobcares.com/blog/plesk-error-fpm-initialization-failed/
On a related note I was testing disabling daemonize in php.ini
for PHP 7.4 on that DediPath machine, but seems like it didn't make any difference:
https://github.com/littlebizzy/slickstack/blob/master/modules/php-fpm/7.4/php-fpm-conf.txt
Strangely it seems like it was a common error before when using Plesk:
Ref: https://talk.plesk.com/threads/plesk-php-7-3-fpm-service-failed-to-start.358336/ Ref: https://bobcares.com/blog/plesk-error-fpm-initialization-failed/
From the Bobcares page:
ERROR: Unable to set priority for the master process: Permission denied (13) Sometimes, users notice that the plesk-php73-fpm on the server suddenly stopped working and cannot be started again. When we try to start the service via
/etc/init.d/plesk-php73-fpm
, it failed with the following message in error log:NOTICE: configuration file /opt/plesk/php/7.3/etc/php-fpm.conf test is successful ERROR: Unable to set priority for the master process: Permission denied (13) ERROR: FPM initialization failed This could trigger due to missing or orphaned php-file in /etc/php/7.0/fpm/pool.d/ or some other folder.
Our Support Engineers run the command below initially to run a repair task:
plesk repair web -php-fpm-configuration
An uninstall plesk-php73-fpm and then reinstall of it often helps to fix the error.
The issue linked above from a few years ago seems related, possibly exactly the same. The OP never mentioned but I suspect he was running an OpenVZ server.
On my test OpenVZ server that experienced this problem, I tried deleting www.conf
and restarting.
Ref: https://forum.hestiacp.com/t/failed-to-start-the-php-7-4/4235/2
But with no luck. I also noticed that sudo service php7.4-fpm status
seemed to produce inconsistent ouput. And, more lines beginning with Process:...
than normal.
At one point I saw:
sudo service php7.4-fpm status
● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2023-07-22 20:16:37 UTC; 11h ago
Docs: man:php-fpm7.4(8)
Process: 1860101 ExecStart=/usr/sbin/php-fpm7.4 --nodaemonize --fpm-config /etc/php/7.4/fpm/php-fpm.conf (code=exited, status=78)
Process: 1860104 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, status=0/SUCCESS)
Process: 1860820 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, status=0/SUCCESS)
Process: 1860834 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, status=0/SUCCESS)
Main PID: 1860101 (code=exited, status=78)
Status: "Ready to handle connections"
Jul 23 07:35:11 linux.example.com systemd[1]: php7.4-fpm.service: Unit cannot be reloaded because it is inactive.
Jul 23 08:01:35 linux.example.com systemd[1]: php7.4-fpm.service: Unit cannot be reloaded because it is inactive.
Warning: journal has been rotated since unit was started, output may be incomplete.
I tried purging all PHP packages and reinstalling multiple times, and rebooting, with no luck.
It seems to be permissions related, but I don't know what permissions need to be adjusted, and I don't know how much this may vary between cloud providers.
Also, several threads floating around where users had to manually create /run/php
directory, but that's not the case here and the directory has always existed fine. Also, not using sockets, so certain discussions are irrelevant.
This error comes up with the PHP-FPM module not starting correctly in OpenVZ seems... at least on the DediPath server that I was testing SlickStack on. Not much info about this error online.
Source code for the error: https://github.com/php/php-src/blob/master/sapi/fpm/fpm/fpm_unix.c