CentOS: additional php versions failed state with ISPconfig3

There are a lot of tutorials showing how to add additional php versions to ISPconfig3. Yet on CentOS, Ubuntu,… one major issue remains: inconsistencies for ISPconfig to restart php-fpm over all php-versions in use.

Possible symptoms are:

• one php-fpm version doesn’t start and all attached websites are unavailable
• a version change is not active
• php-ini changes are not applied
• …

Underlying issue

The reason for those issues comes mostly due to systemd handling startups in a strict way. Two issues can arise with ISPconfig3:

1. When ISPconfig3 restarts all php-fpm over all php versions, only the default version is stopped. Similarly upon start only the default version is started. As a result, the changes to any other php-version except the default version are not applied.
2. Alternatively ISPconfig3 restarts all php-fpm versions by first stopping all php-fpm versions. Then upon start only the default php-fpm of the default OS php version is started. So all other php-fpm services are still inactive. Corresponding websites are down.

Solution

There are a lot of solutions and quick fixes, some in ispconfig itself (which sometimes don’t really work). Yet the most safe and straightforward way is: changing the systemd properties of all php-fpm services involved.

The Hack

A quick and dirty solution (apart from changing systemd files) is changing the php-script in ISPconfig3. First of all we determine our php-fpm.service names.

Now we just edit /usr/local/ispconfig/server/mods-available/web_module.inc.php and search for the “systemctl restart php-fpm” statement and change it accordingly.

Yes that line is two times in web_module.inc.php, hence why I listed it two times. This solves the issue for the time being, but is a poor solution:

1. On any change to php-fpm versions or service name changes, we need to remember where we  changed what in ISPconfig3.
2. Upon any ISPconfig3 update our modified version is most likely – gone. Overwritten by a newer version.

The smartest way would be a patch in ISPconfig3, where all systemd service files are listed and ISPconfig3 only restarts the php-fpm service of a specific php-version. Then again ISPconfig3 is not really written for CentOS, but more for Debian and Ubuntu – so I do not see such a patch coming.

Change phpXX-fpm service-files

A slightly better option is to connect all php-fpm versions to a php-fpm-“block”. So we simply tell php-fpm.service, that it wants all the other php-fpm-services too. Since ISPconfig3 triggers systemctl restart php-fpm it will also start the other php-fpm versions. Making php-fpm.service some kind of “master-service”.

First of all we find all our php-fpm services like we did before:

In a second step we tell /lib/systemd/system/php-fpm.service that it needs the others too. So we modify php-fpm.service as follows:

 

By adding this line, we tell php-fpm.service to also start php56-fpm and php7-fpm.service. So whenever php-fpm.service starts, those two will be triggered too. Alternatively we could have done a “Requires” directive. Yet given the nature of CentOS and ISPconfig, I would advise against strict rules here, but suggest the less restrictive “Wants” here.

Change phpXX-fpm.service with “BindsTo”

But what happens if php-fpm.service stops? Nothing. For that we also modify the phpXX-fpm.service files as follows:

We do the same for php70-fpm and php72-fpm.service

So for any additional phpXX-fpm version we add the service to php-fpm.service in the “Wants” directive and we add “BindsTo=php-fpm.service” as shown above.

To clean all up, we reload:

Done.

Result

By this change a start of php-fpm automatically triggers the other phpXX-fpm services. If those dont start up or fail, php-fpm starts nonetheless. As soon as php-fpm.service is stopped, the other phpXX-fpm services are stopped immediatly too.

Additional information

The ispconfig team added some quickfixes for Ubuntu and CentOS. Of course these “quick-fixes” do not automatically include new php-versions. This leads exactly to the issues mentioned in the introduction. While the last solution as shown eases those issues.