OpenVZ PHP-FPM "Unable to set priority for the master process: Permission denied"

[jessuppi]

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

[jessuppi]

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/

[jessuppi]

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

[jessuppi]

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.

[jessuppi]

https://slickstack.io/forum/topic/php-fpm-fails-on-openvz-server-from-dedipath

[jessuppi]

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.

[jessuppi]

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.

[jessuppi]

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.

[jessuppi]

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.

Ex: https://forum.openmediavault.org/index.php?thread/44477-cannot-login-in-the-web-interface-502-bad-gateway-failed-to-start-the-php-fastcg/