@TimReeves
Well, it is not "whinging" at all, to the contrary: your specific situation often is the culmination of multiple (minor) previous errors.
Normally, one would consider the most elaborate solutions, including command line actions and all kinds of analysis, but that should not really be necessary: Plesk is more than decent, in the sense that it is able to correct some of your issues by just switching php versions and/or fpm modules.
Try the following (after having checked first that you are on micro-update 17 or 18):
a) with respect to the fpm issue:
1 - go to the troublesome domain in question and go to "PHP Settings": change "FPM served by ..." to "Fastcgi application served by Apache", (and)
2 - if that works, revert the settings by undoing your changes: select "FPM served by Apache" again and it should work fine.
If you encounter any problems (error notifications in red), just retry step 1 and verify in a SSH console that /var/www/vhosts/system/<domain> does not contain a php-fpm.sock file (and if it does, just delete it and execute before mentioned step 2).
Note that you really have to press "OK" (and not "Apply") when executing steps 1 and 2.
Also note that the above "solution" is not dependent on the version of php, it should work for all php versions.
Having said (or repeated) the above, we can continue to your actual statement.
b) with respect to the php issue: you stated
But I did just notice something else disturbing: My Plesk had long updated PHP to 7.0.1 - but 7.0.0 was still being served! Really, I saw it on phpinfo(). I was looking at phpinfo() because Plesk had just again failed to restart the master process for the pool of PHP 7.0, after I had reassigned a new domain to it (away from default OS-Vendor PHP). The FPM log was noting that a socket appeared to be already set by another FPM instance. Well, that was the still-running 7.0.0. A manual restart "service plesk-php70-fpm restart" did the trick, now I'm seeing 7.0.1 and there was no problem to restart the FPM instance. Maybe Plesk needs to be using more "restart" than "start"? That way, it does'nt matter if an instance is already running or not, making things more robust.
The restart command is nothing more (or less) than a sequence of stop and start (i.e. it is not a graceful restart).
In essence, an educated guess would be that your previous version of php has been claiming a php socket at installation time of the new php version: a failure to stop properly would result in a failure to start the new php version at post-installation time, whereas before mentioned failure to stop (the old php version) would be caused by (previous) stop/start failures of the old php version, with the latter stop/start failures often being the result of manual actions (and not being the result of Plesk running improperly).
After all, it has always been possible to "activate" or, if necessary, "enforce" the start of fpm via the Plesk panel, irregardless of the php version (see section a)).
Sure, I must admit that some of the earliest versions of Plesk 12.5.30 did cause some minor problems, but these were patched, implying that a failure caused by Plesk is not very likely to be the underlying root cause of a number of consecutive (minor) problems.
For that reason alone, I must emphasize that section a) contains an approach that will end the sequential occurrence of php/fpm related issues.
In short, it is not an issue of starting or restarting, as you stated, but more or less a matter of manual actions.
To be honest, I also forget to undo some settings, when I try to reproduce an error: this can lead to "false negatives", i.e. issues that are not issues at all, but human mistakes.
In conclusion, it is my humble advice to start from scratch and/or systemically think about all possible explanations, whenever tackling any issue.
Regards....
Facebook
Twitter
