Submitted by unsalkorkmaz on Tue, 02/13/2018 - 08:07
Hi, I installed php7.2 version and has 7.0 that came with virtualmin as default. I couldnt find switch from php7.0 to 7.2 when using php-fpm as PHP script execution mode. Is there any documentation about this?
Status:
Closed (fixed)
Comments
Submitted by andreychek on Tue, 02/13/2018 - 10:35 Comment #1
Howdy -- unfortunately, due to the nature of how PHP-FPM works, it's not possible to switch between multiple PHP versions. You'd need to be using CGI/FCGID for that.
It looks like you're using Virtualmin GPL there though... if you're using Virtualmin GPL, and you had any followup questions, you'd want to use the Forums for support.
We monitor the Forums, along with lots of wonderful folks in the community. Thanks!
Submitted by JamieCameron on Wed, 02/14/2018 - 00:03 Comment #2
In theory we might support this in future, but right now only one FPM version can be selected.
Submitted by gnilebein on Sun, 02/18/2018 - 16:11 Comment #3
+1 for multiple php versions for fpm
Submitted by bhelm on Wed, 03/07/2018 - 12:14 Comment #4
@andreychek you are wrong. It is perfeclty possible to run multiple php-fpm versions on different ports/sockets, like one for each virtual server. (i thinks its already done the way that there is a fpm pool per virtual server, there is just no version switch, but i need to check).
This is the #1 feature for me, the only thing i am missing when coming from Plesk. In Plesk you can switch versions on per-domain (virtual server) basis, which is totally sufficient for most projects. Different FPM-Versions per Directory is a feature that i would'nt miss (while i also think that this is possible with php-fpm!).
Submitted by JamieCameron on Wed, 03/07/2018 - 17:39 Comment #5
Yes, multiple FPM versions is technically possible with the right configs - we just have to implement it in Virtualmin.
Submitted by gnilebein on Thu, 03/08/2018 - 14:16 Comment #6
I would be very grateful if you could add this feature.
Submitted by JamieCameron on Fri, 03/09/2018 - 00:07 Comment #7
It's on our TODO list.
Submitted by h2ojunkie on Mon, 04/16/2018 - 23:10 Comment #8
+1 on this. Glad to hear its on the todo!
Submitted by ashishamre on Sun, 06/24/2018 - 23:57 Comment #9
Is PHP Switching through Virtualmin possible now, how soon can we get this feature.
I have tried FCGID but it does not reflect version I changed, do I need to do anything else before and after changing PHP version.
Submitted by JamieCameron on Mon, 06/25/2018 - 00:05 Comment #10
Multiple versions are still only supported in CGI and fCGId modes.
Submitted by jrobinet-silvertech on Tue, 07/03/2018 - 11:25 Pro Licensee Comment #11
Hello,
I need to run php7.2, but I cannot make it work ;-( Is it possible? If yes what's the best way?
Thanks in advance.
Submitted by andreychek on Tue, 07/03/2018 - 12:31 Comment #12
We'd be happy to talk about PHP 7.2! Though that's a different issue than the posts above. Could you open a separate request for that? Then we won't get the topics here too mixed up. Thanks!
Submitted by bhelm on Wed, 07/04/2018 - 00:43 Comment #13
The Problem is that virtualmin sticks to one PHP Version for FPM. If you install i.e. PHP 7.2 in addition to 7.0 you are not able to select it for PHP-FPM. This can be worked around by uninstalling all other PHP-FPM variants (cgi and others can remain). If PHP 7.2 is the only PHP-FPM version left installed, it will be selected. A virtualmin Configuration check/rescan could be required.
Submitted by JamieCameron on Wed, 07/04/2018 - 13:48 Comment #14
Right, multiple FPM version support is still in the works.
Submitted by denisr on Sat, 10/06/2018 - 11:42 Comment #15
If I have only php72 from remi installed, I can't select FPM mode: Failed to save website options : No PHP versions found for mode fpm FPM pool is running ok.
Submitted by Jfro on Sat, 10/06/2018 - 12:07 Comment #16
Only one php version in fpm should work. Even the remi one.
If you have somewhere config another in the fpm mode then no, that is virtualmin for the moment not supporting. No matter wich repo is used. UH normally you don;t have only one remi php , you still ( should) have the default virtualmin php's somewhere i think, while wiping them virtualmin php's completly wasn't working before.
You have to configure set first the default php version for the virtual server. Only after that you can switch / set for that virtualserver and php version to the fpm mode.
Don;t know by head were these 2 parts are in the panel, but at 2 diferent places , i have to search myself each time before i can set fpm, to have the php version set right at another places in the panel. ( so first select the php version , then go to the other place where you can choose the fpm mode.)
Submitted by denisr on Sat, 10/06/2018 - 12:27 Comment #17
Yes, I have only one version - 7.2. Default 5.4 and 7.0 was removed. There is new install, only removed all php and installed new one. There is no any debug log from save_phpmode.cgi?mode=fpm , so I don't know what error inside.
virtualmin check-config
The following PHP versions are available : 7.2.10 (/bin/php72-cgi), 7.2 (mod_php)
PHP-FPM support is available on this system.
PHP versions have changed to 7.2, 7.2 since last check. Regenerating any missing php.ini files.
ps aux | grep fpm
root 1069 0.0 0.0 476968 14032 ? Ss 14:59 0:00 php-fpm: master process (/etc/opt/remi/php72/php-fpm.conf)
apache 1070 0.0 0.0 476968 7000 ? S 14:59 0:00 php-fpm: pool www
apache 1071 0.0 0.0 476968 7000 ? S 14:59 0:00 php-fpm: pool www
apache 1072 0.0 0.0 476968 7000 ? S 14:59 0:00 php-fpm: pool www
apache 1073 0.0 0.0 476968 7000 ? S 14:59 0:00 php-fpm: pool www
apache 1074 0.0 0.0 476968 7004 ? S 14:59 0:00 php-fpm: pool www
cat /etc/opt/remi/php72/php-fpm.d/www.conf
listen = 127.0.0.1:9000
Also there is no listen = /var/run/php-fpm.sock
Submitted by JamieCameron on Sun, 10/07/2018 - 02:01 Comment #18
Sure, one PHP version should work. Did you already open a separate bug for this?
Submitted by monsieurQ on Mon, 10/15/2018 - 09:26 Comment #19
Running Centos6, I have multiple php versions installed including php-fpm for php7.2 only. Selecting FPM as execution mode forces the php version to go to 5.3 which is obviously not ideal. Even changing the default PHP version to 7.12 makes no difference.
The real issue here is that Joomla is aggressively pushing a Php7.x min for the soon to be released versions and running 7.12 without FPM (for me at least) is unusable due to mem allocation erros such as this: https://www.virtualmin.com/node/36588).
In short... +1 for FMP support for multiple php setups.
Submitted by kpendic on Tue, 10/16/2018 - 06:11 Comment #20
Hi guys,
is there any ETA for that functionality?
thanks
Submitted by andreychek on Tue, 10/16/2018 - 09:17 Comment #21
It's on the todo list for the future, though we unfortunately don't have an ETA at the moment.
In the meantime you can select different PHP versions using FCGID/CGI.
Submitted by kpendic on Tue, 10/16/2018 - 20:17 Comment #22
Yes I know for selecting diff version via FCGID/CGI mode but fpm..
is there a way to do it manualy, or by cli? I'd tried something like this:
mv /etc/php/7.0/fpm/pool.d/1*.conf /etc/php/7.2/fpm/pool.d
systemctl -a restart php7.0-fpm && systemctl -a restart php7.2-fpm
and for now it works, but I have a filling that I'm missing something ..
Submitted by JamieCameron on Fri, 12/28/2018 - 22:57 Comment #23
Ok, after much work support for running multiple PHP-FPM versions and being able to select a version on a domain-by-domain basis has been implemented in Virtualmin. This will be included in the next release.
Submitted by bhelm on Wed, 01/02/2019 - 06:26 Comment #24
Great! looking forward for testing this.
Submitted by monsieurQ on Wed, 01/02/2019 - 06:30 Comment #25
This is great news! Many thanks for your work on this.
Submitted by kpendic on Wed, 01/02/2019 - 06:55 Comment #26
Great news,
thanks a bunch for this! Looking forward to this!
Submitted by geissweb on Sun, 01/27/2019 - 03:38 Comment #27
Is there any estimation regarding the release date where this is included? :)
Submitted by JamieCameron on Sun, 01/27/2019 - 12:25 Comment #28
Couple of weeks at most.
Submitted by fbeckma on Wed, 02/13/2019 - 05:40 Comment #29
Hi,
my version is 6.06-gpl
great the mutable php-fpm has now been installed. however, this does not work in my installation. he does not recognize the other php versions.
these are all displayed as version 7.0.33. even switching between versions does not seem to work. Installed are 5.6, 7.0, 7.1, 7.2 and 7.3
Submitted by JamieCameron on Wed, 02/13/2019 - 21:52 Comment #30
If you go to System Settings -> Re-Check Configuration , what PHP-FPM versions does it report as being available?
Submitted by fbeckma on Thu, 02/14/2019 - 02:04 Comment #31
Hi,
The following PHP-FPM versions are available on this system : 7.0.30 7.1.26 7.2.15 7.3.2 7.3.2 5.6.39 5.6.39
Submitted by kpendic on Thu, 02/14/2019 - 02:07 Comment #32
@fbeckma how did you get 6.06 version? I'm on 6.05 and no updates to newer version? thx
Submitted by fbeckma on Thu, 02/14/2019 - 02:22 Comment #33
Hi,
http://webmin.com/vdownload.html
Submitted by geissweb on Sun, 02/17/2019 - 01:33 Comment #34
Virtualmin 6.0.6 When I re-check the config I get:
The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.1.26 (/usr/bin/php-cgi7.1), 7.2.15 (/usr/bin/php-cgi7.2) The following PHP-FPM versions are available on this system : 7.0
Of course the other FPM versions are installed too.
Submitted by kpendic on Sun, 02/17/2019 - 04:48 Comment #35
I have almost the same message saying:
but
systemctl status php7.2-fpm
&systemctl status php7.0-fpm
report FPM is enabled and active.I have feeling virtualmin is not detecting fpm versions on system correctly?
Submitted by mikt on Mon, 02/18/2019 - 07:18 Comment #36
I can second that - same here - two versions detected for cgi - one for fpm
Submitted by draxius on Mon, 02/18/2019 - 18:27 Comment #37
So, I think I figured out why this detection issue is happening while troubleshooting this for our local (Debian) server.
There's a section of code in php-lib.pl that starts the detection of php-fpm versions by package name (currently this starts at line 1709):
foreach my $pname ("php-fpm", "php5-fpm", "php7-fpm",
(map { my $v=$_; $v =~ s/\.//g;
("php${v}-php-fpm", "php${v}-fpm", "rh-php${v}-php-fpm") }
@all_possible_php_versions)) {
That last variable is defined in virtual-server-lib.pl as: @all_possible_php_versions = (5, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9,"7.0", 7.1, 7.2, 7.3);
The problem is, the "map" function in the above code means that any "dot" in the package name is stripped for the check - the code will look for a package named php72-fpm, but not php7.2-fpm. That's a huge problem for Debian, which distributes FPM using the latter naming style.
I was able to verify that I can get the config check to detect all installed versions with the code below. I have not tested further than this, and have reverted this change on my own machine. I'm putting this out there for others to review, with no guarantee it will work.
foreach my $pname ("php-fpm", "php5-fpm", "php7-fpm",
(map { my $v=$_; $v =~ s/\.//g;
("php${v}-php-fpm", "php${v}-fpm", "rh-php${v}-php-fpm") }
@all_possible_php_versions),
(map { my $v=$_;
("php${v}-php-fpm", "php${v}-fpm", "rh-php${v}-php-fpm") }
@all_possible_php_versions)) {
Note that the 5th line and 8th line of the code above differ (and it needs to be that way to parse). This basically does a check for the package versions "with dots" (5.6, 7.2, etc) after the one "without dots" (56, 72, etc).
Hopefully the maintainers can take a look a see if this is a valid solution, and something worth rolling into the production code.
Submitted by JamieCameron on Mon, 02/18/2019 - 20:17 Comment #38
Thanks for pointing this out - you're correct that a package named like php7.2-fpm won't be detected when it should be. We'll fix this in the next release.
Submitted by kpendic on Mon, 02/18/2019 - 20:35 Comment #39
Huge props draxius, for helping community and all users out there!
+1
Submitted by draxius on Mon, 02/18/2019 - 20:37 Comment #40
I just updated php-lib.pl with the version in github, which shows a similar change (one that should be more efficient than what I wrote).
When I then run
virtualmin check-config
from the command line, I get the output: "The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.2.15 7.3.2"When I trigger System Settings->Re-Check Configuration through the Virtualmin portal, however, I'm still getting: "The following PHP-FPM versions are available on this system : 7.0"
I'm very confused as to why the output of these two versions of the config check would differ, but any guidance would be appreciated.
Submitted by fbeckma on Tue, 02/19/2019 - 02:18 Comment #41
hi,
same here. "virtualmin check-config" from command line: The following PHP-FPM versions are available on this system : 5.6.39 5.6.39 5.6.39 7.0.30 on portal: The following PHP-FPM versions are available on this system : 7.0.30 7.1.26 7.2.15 7.3.2 7.3.2 5.6.39 5.6.39
portal -> Server configuration -> PHP Versions: available php versions are 5x 7.0.33 an 2x 5.6.39
Submitted by jpl166 on Tue, 02/19/2019 - 09:49 Comment #42
I'm working with draxius on the same server. The command line / webUI disconnect was just a restart of miniserv to fix.
However, with the replacement of the one file (php-lib.pl) from the new checked-in version on github, we can try and flip sites to other versions of PHP-FPM. I see 7.0, 7.2, and 7.3 in the dropdown, I take a test site and flip it to 7.3. Looking in /etc/php/7.3/fpm/pool.d I see... nothing. I try 7.2, nothing. I drop a phpinfo.php in to the document root and nothing I do actually changes which PHP version it's using. So the dropdown is implemented, but it's not actually doing anything under the covers other than saving the php_fpm_version in the appropriate file in /etc/webmin/virtual-server/domains.
Submitted by draxius on Tue, 02/19/2019 - 16:37 Comment #43
It appears that the problem we've been seeing (even after fixing the above issue with restarting the webmin miniserv - which is also required after the fix below) is based on how the version numbers are being parsed in the "Config directory for per-domain pool files" section of list_php_fpm_configs (this is also in php-lib.pl).
The function, as written, currently returns the first entry of @verdirs, rather than matching. The reason for this is because of the strings it is trying to match on: 'version' (7.2.15) and 'pkgversion' (72), ignoring 'shortversion' (7.2). Our Debian system consistently uses the format /etc/php/${shortversion}/fpm/pool.d for the pool directories, rather than the other two formats.
Below is the change-set I used to fix this:
--- php-lib.pl_pre-fix 2019-02-18 21:26:08.618385355 -0500
+++ php-lib.pl 2019-02-19 17:25:53.878412062 -0500
@@ -1754,7 +1754,8 @@
next;
}
my ($bestdir) = grep { /\Q$rv->{'version'}\E/ ||
- /\Q$rv->{'pkgversion'}\E/ } @verdirs;
+ /\Q$rv->{'pkgversion'}\E/ ||
+ /\Q$rv->{'shortversion'}\E/ } @verdirs;
$bestdir ||= $verdirs[0];
$rv->{'dir'} = $bestdir;
IMPORTANT NOTE before trying to implement this change, you will need to revert any/all virtual hosts back to their original php-fpm versions, especially if you have 3+ versions on your system. If you don't, you will have an open port from your original version, which will prevent the newer version's master process from spawning at all.
As with the last time, I'm not guaranteeing this patch will work for you. I'll simply pointing out the quick fix we made on our end to get this un-jammed. YMMV.
Submitted by fbeckma on Wed, 02/20/2019 - 02:30 Comment #44
here the pool config is indeed pushed into the correct version but it comes to an error:
"[20-Feb-2019 09:17:52] ERROR: unable to bind socket for address '8002': Address already in use (98) [20-Feb-2019 09:17:52] ERROR: FPM initialization failed "
Here also directly the question if you could not switch to socket. and also directly for all php versions the config is created, thus one can jump in the web between the php versions.
also here are still or again only the php versions "The following PHP-FPM versions are available on this system: 5.6.39 5.6.39 5.6.39 7.0.30" displayed.
that's me but a few 5.6er too much :)
System debian 9.7 php-fpm: 5.6, 7.0 7.1 7.2 7.3 config: /etc//fpm/pool.d/ 7.1-x.3 are optional packages binery are located in / opt / php- /
Submitted by draxius on Wed, 02/20/2019 - 16:48 Comment #45
fbeckma,
I think you're running into two issues.
1) I suspect you applied the changes to the 6.06 release version of php-lib.pl, rather than an already updated version that incorporated the first fix. Here's a patch for the combined changes if you need it:
--- php-lib.pl.6.06.dist 2019-02-18 19:43:20.317226557 -0500
+++ php-lib.pl 2019-02-19 17:25:53.878412062 -0500
@@ -1707,8 +1707,9 @@
&foreign_require("software");
my @rv;
foreach my $pname ("php-fpm", "php5-fpm", "php7-fpm",
- (map { my $v=$_; $v =~ s/\.//g;
- ("php${v}-php-fpm", "php${v}-fpm", "rh-php${v}-php-fpm") }
+ (map { my $v = $_; $v =~ s/\.//g;
+ ("php$v-php-fpm", "php$v-fpm",
+ "rh-php$v-php-fpm", "php$_-fpm") }
@all_possible_php_versions)) {
my @pinfo = &software::package_info($pname);
next if (!@pinfo || !$pinfo[0]);
@@ -1753,7 +1754,8 @@
next;
}
my ($bestdir) = grep { /\Q$rv->{'version'}\E/ ||
- /\Q$rv->{'pkgversion'}\E/ } @verdirs;
+ /\Q$rv->{'pkgversion'}\E/ ||
+ /\Q$rv->{'shortversion'}\E/ } @verdirs;
$bestdir ||= $verdirs[0];
$rv->{'dir'} = $bestdir;
2) The "address already in use" error you are receiving is because the original pool configuration file (from before you made the code change) is probably still sitting in the old pool location. What we experienced (before this latest fix) was after we tried to move a site from 7.0->7.2, the 7.0 and 7.2 FPM master processes restarted. When we tried to move from 7.2 to 7.3, the 7.2 and 7.3 processes restarted. And so on.
The problem was, the pool file was not being written to the 7.2 or 7.3 directories until I changed the code (as per my prior post). Once I did, the 7.0 file was still left behind, because we kept trying to flip between 7.2 and 7.3 to prevent constant restarts on the (production) 7.0 pools. So when 7.2 restarted, we got the same "address already in use" error that you're seeing.
What you need to do to fix that is to find the old pool file that got left behind while you were trying to fix it, delete that file (or move it out of the way), and then restart the old php-fpm master daemon (in our case, this was php7.0-fpm). After that, you can try restarting the process that failed to run (the one you tried to move that virtual site to).
Submitted by geissweb on Thu, 02/21/2019 - 06:59 Comment #46
I still can't get it to work. Base version 6.0.6. I replaced the full php-lib.pl from github (https://github.com/virtualmin/virtualmin-gpl/blob/master/php-lib.pl) and then I applied the changes suggested by draxius
- /\Q$rv->{'pkgversion'}\E/ } @verdirs;
+ /\Q$rv->{'pkgversion'}\E/ ||
+ /\Q$rv->{'shortversion'}\E/ } @verdirs;)
But on CLI:
The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.1.26 (/usr/bin/php-cgi7.1), 7.2.15 (/usr/bin/php-cgi7.2)
The following PHP-FPM versions are available on this system : 7.0
And over the UI recheck-config:
The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.1.26 (/usr/bin/php-cgi7.1), 7.2.15 (/usr/bin/php-cgi7.2)
The following PHP-FPM versions are available on this system : 7.0
Submitted by kpendic on Thu, 02/21/2019 - 07:03 Comment #47
I can second that as @geissweb, only one version for FPM is found!
Submitted by fbeckma on Thu, 02/21/2019 - 07:47 Comment #48
Hi,
the error "Address already in use" is fixed.
however, the list still looks the same. PHP Versions In domain displays 6x7.0.33 and 3x5.6.39 However, it is as if the versions would be moved so the conf in the pools of the respective php version.
Manage PHP Configuration /etc/php/7.0/fpm/pool.d/15507558235986.conf (FPM format) always points to php7.0 although I have selected version 7.2 (blind).
here again the question if it is possible to switch the pools to sock and not to run on TCP. advantage less overhead and it can run multiple PHP versions per domain.
Maybe a checklist where the available versions for the web can be turned on and off.
Submitted by fbeckma on Thu, 02/21/2019 - 08:23 Comment #49
I just tested something. unfortunately the error with the old php version still exists the previous php-fpm will not be restarted. so that the port is still occupied.
Submitted by draxius on Thu, 02/21/2019 - 09:00 Comment #50
@geissweb, @kpendic As a reminder, we discovered that after replacing php-lib.pl, we had to restart webmin before the UI used the updated version. Can you restart that and then Re-Check Configuration through the UI?
@fbeckma It sounds like you're running into the problem we were earlier (which was the whole point of comment #43), but it's not clear what changes you have in place on php-lib, so I can't really provide much more info without knowing what your state is.
Submitted by geissweb on Thu, 02/21/2019 - 09:29 Comment #51
Thanks @draxius for helping us here!
But unfortunately I restarted webmin several times, problem persists. I can only hope that this issue has high est priority for the developers...
I get the same output for the "virtualmin check-config".
I replaced and edited the php-lib.pl in /usr/share/webmin/virtual-server/ (Debian 9) - that is the correct location right?
Submitted by fbeckma on Thu, 02/21/2019 - 09:44 Comment #52
I downloaded the php-lib.pl from github and then executed the patch from # 43.
here the diff
diff php-lib.pl-git php-lib.pl
1757c1757,1758
</ \ Q $ rv -> {'pkgversion'} \ E /} @verdirs;
---
> / \ Q $ rv -> {'pkgversion'} \ E / ||
> / \ Q $ rv -> {'shortversion'} \ E /} @verdirs;
service webmin restart
virtualmin check-config
then I see several equal php versions.
Submitted by draxius on Thu, 02/21/2019 - 12:26 Comment #53
@geissweb I'm happy to help as I have the time. This isn't a burning issue for us any more, but I'm able to squeak in a few responses here and there.
To be extremely specific, we're running webmin-virtual-server_6.06.gpl (via Debian package) on a Debian 9 server with all packages on the system up to date. The only file difference in the entire /usr/share/webmin/ tree is /usr/share/webmin/virtual-server/php-lib.pl (as detailed in comment #45).
The "list_php_fpm_configs" subroutine (starts line 1700 of php-lib.pl) is entirely dependent on which php-fpm packages you have installed on the system, and is based on the local package manager (dpkg). You should be able to list those with
dpkg -l
, and the desired output should include not just php-fpm as a package, but also php7.0-fpm and php7.2-fpm (at a minimum). If those packages do not exist, the version checker won't find the other versions.Submitted by draxius on Thu, 02/21/2019 - 12:31 Comment #54
@fbeckma Looking through the code, I'm not seeing why you'd have an issue detecting the correct php-fpm versions on the system. It definitely looks like you've got both code changes in place.
Let me know if you're still having issues with the socket/port side of things - I can walk you through what I did to get that fully resolved (it was a bit of a pain for me at first). We can at least get you back to a pristine state.
Submitted by geissweb on Thu, 02/21/2019 - 14:41 Comment #55
Thanks again @draxius, I've got it working now. I applied your complete patch on a 6.0.6 fresh version:
The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.1.26 7.2.15
:)The only problem now is that the config edit links are still referencing the old 7.0 version like
/etc/php/7.0/fpm/pool.d/154695539811782.conf
, but I can edit it manually in the /7.2/ folder.Submitted by draxius on Thu, 02/21/2019 - 15:10 Comment #56
We had that same problem at first @geissweb - this is what led to our initial "Address already in use" issue.
You want to make sure that 154695539811782.conf (to use your example) doesn't exist in both the 7.0 and 7.2 folders, otherwise you'll get the port conflict.
One approach you can take is edit the site that "should be" 7.2, but is displaying in 7.0 - if you set the site's PHP-FPM Version back to 7.0, you'll functionally re-sync reality with what Virtualmin things is going on. Then you can move the site back to 7.2 and it should work.
If you have moved more than one site already, this gets a little trickier - you'll want to revert all of them back to the pre-patch version (which I presume is 7.0.33) first before you reset any of them to 7.2. Any other setting customizations you've made should stay in place, so you shouldn't have to worry about that, but you obviously want to get back to a state where you can seamlessly slide between PHP versions without concern.
Submitted by geissweb on Fri, 02/22/2019 - 01:04 Comment #57
@draxius Yes, the conf is in the correct folder on the server. I had the sites running on fpm-7.0 before I did anything, it works well. I just mean the link to edit the fpm-conf in the virtualmin UI still points to the 7.0 folder, although the conf was placed correctly in the 7.2 folder. I hope that it will be addressed in the official release.
@fbeckma Don't use the latest github version. Just take a vanilla 6.0.6 php-lib.pl and apply the patch as stated in comment #45. Set your domains to use 7.0-fpm before you recheck the config.
Submitted by fbeckma on Fri, 02/22/2019 - 04:28 Comment #58
Hi,
I have loaded the github php-lib.pl 6.0.6 and applied the patch from # 45.
unfortunately still the same result. Manage PHP Configuration /etc/php5/fpm/pool.d/155083067221739.conf (FPM format) here is the file to lie, but is in /etc/php/7.0/fpm/pool.d/
The following PHP-FPM versions are available on this system: 5.6.39 5.6.39 5.6.39 7.0.33
@draxius I would be interested in the config for socket
Submitted by draxius on Fri, 02/22/2019 - 10:35 Comment #59
@fbmecka, it looks like the UI has (yet another) bug, as pointed out by @geissweb's last post. The test sites we've moved to 7.2 and 7.3 still show /etc/php/7.0/fpm/pool.d/ as the file path, and editing the config file manually through the UI no longer works on those sites.
To validate which config is really in use, just look for these two files: /etc/php5/fpm/pool.d/155083067221739.conf /etc/php/7.0/fpm/pool.d/155083067221739.conf
If only one exists, and your site is served properly, then then the patch I recommended handles getting things working generally, but I haven't even started looking at a solution for the "Manage PHP Configuration" page as of yet.
Submitted by draxius on Fri, 02/22/2019 - 12:33 Comment #60
Found it!
In feature-web.pl (should be in the same folder as php-lib.pl Change line 2337 from:
to:
The current line returns the "default" fpm config, and the modified line returns the config for the virtual server you're configuring.
This is the function used to build the "PHP-FPM Configuration" link on the menu, which is why it gets all out of whack.
After editing this file, you must: 1) Restart the webmin miniserv (
service webmin restart
on Debian) 2) "Re-check configuration" through the UI again.After that, the links should show up properly. Ideally, this will close the loop on this problem, but once again, no guarantees.
Submitted by geissweb on Fri, 02/22/2019 - 14:10 Comment #61
Thanks so much @draxius :)
Submitted by JamieCameron on Sun, 02/24/2019 - 22:43 Comment #62
Thanks for pointing out this bug in feature-web.pl - it will be fixed in the next release.
Submitted by geissweb on Mon, 02/25/2019 - 03:46 Comment #63
Unfortunately I think there is still work to do. I have got the update to 6.0.6-gpl2 on Debian9 on another server and with that version I even don't see FPM as option to run PHP on in the settings.
I only see mod_php (which is completely uninstalled on the server) and the cgi/fcgi options. Check config shows:
Die folgenden PHP Versionen sind verfügbar : 7.0.33 (/usr/bin/php-cgi7.0), 7.1.26 (/usr/bin/php-cgi7.1), 7.2.15 (/usr/bin/php-cgi7.2), 7.3.2 (/usr/bin/php-cgi7.3), 7.0 (mod_php)
The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.1.26 7.2.15 7.3.2
UPDATE:
I was able to get the FPM selection back after I changed the corresponding /etc/webmin/virtual-server/domains/.conf, from:
php_fpm_version=5
tophp_fpm_version=7.2
Submitted by draxius on Mon, 02/25/2019 - 10:31 Comment #64
@geissweb I downloaded and extracted the files in gpl2, and it looks like this is a release to address other issues, not the PHP ones we've been discussing. GitHub still isn't caught up with all of the fixes above, and it looks like the new Debian package was released prior to that check-in.
@JamieCameron As we were discussing starting at comment #43, the file path detection for pool configurations seems to suffer from a similar "bug"(?) on Debian, where it cannot find the correct /etc/php/7.x/fpm/pool.d path. Below is a patch against that file that fixes this particular problem - this has been tested by several of us already, so it seems to work. Without this change, it looks for paths like /etc/php/7.0.33/ and /etc/php/70, but not /etc/php/7.0 (which is the path structure that Debian uses). Given the stream of text, I'm sure it was pretty easy to miss, though.
--- php-lib.pl 2019-02-25 11:09:32.075630937 -0500
+++ /usr/share/webmin/virtual-server/php-lib.pl 2019-02-25 11:10:11.591103045 -0500
@@ -1754,7 +1754,8 @@
next;
}
my ($bestdir) = grep { /\Q$rv->{'version'}\E/ ||
- /\Q$rv->{'pkgversion'}\E/ } @verdirs;
+ /\Q$rv->{'pkgversion'}\E/ ||
+ /\Q$rv->{'shortversion'}\E/ } @verdirs;
$bestdir ||= $verdirs[0];
$rv->{'dir'} = $bestdir;
We're holding off on patching to the latest Debian package until all the pieces of this are sorted out (we have a working code-base right now, so there's no real rush on our end). To clarify our current state (which works fully), we are running:
If there's any other information I can provide, please let me know.
Submitted by monsieurQ on Mon, 02/25/2019 - 10:34 Comment #65
Many thanks @draxius
Submitted by aschenbr on Mon, 03/04/2019 - 12:09 Pro Licensee Comment #66
When will the official fix be out as my machine is messed as well due to this.
Submitted by sgrayban on Thu, 03/14/2019 - 17:30 Comment #67
Not true on the fpm package.
I have php7.2-fpm installed and when running the VM PRO check I get this....
No PHP-FPM packages were found on this system.
# apt-get install --reinstall php7.2-fpm
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 1,395 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://packages.sury.org/php stretch/main amd64 php7.2-fpm amd64 7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82 [1,395 kB]
Fetched 1,395 kB in 1s (1,330 kB/s)
(Reading database ... 343799 files and directories currently installed.)
Preparing to unpack .../php7.2-fpm_7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82_amd64.deb ...
Unpacking php7.2-fpm (7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82) over (7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82) ...
Setting up php7.2-fpm (7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82) ...
NOTICE: Not enabling PHP 7.2 FPM by default.
NOTICE: To enable PHP 7.2 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.2-fpm
NOTICE: You are seeing this message because you have apache2 package installed.
Processing triggers for systemd (232-25+deb9u9) ...
Processing triggers for man-db (2.7.6.1-2) ...
[root@desktop ~]
# a2enmod proxy_fcgi setenvif
Considering dependency proxy for proxy_fcgi:
Module proxy already enabled
Module proxy_fcgi already enabled
Module setenvif already enabled
[root@desktop ~]
# a2enconf php7.2-fpm
Conf php7.2-fpm already enabled
Submitted by aschenbr on Sat, 03/16/2019 - 14:49 Pro Licensee Comment #68
hello @draxius , in your comment https://www.virtualmin.com/comment/809098#comment-809098
im struggling to make that work. I can change php versions, but the php-fpm will not change to the new version . So i check on my php7.0 pool.d directory and the files are there and never created in the new version of php (in this case php7.1)
your help is appreciated
Submitted by oMikR0n on Sat, 03/23/2019 - 08:34 Comment #69
Any news on this? I am facing the same problem on my server
Submitted by draxius on Mon, 03/25/2019 - 15:03 Comment #70
@aschenbr - The changes I made in the referenced comment modified the version of php-lib.pl found here: https://github.com/virtualmin/virtualmin-gpl/blob/e1987a29dd4c88343ea5e6...
You'll also need the updated feature-web.pl - https://github.com/virtualmin/virtualmin-gpl/blob/9feb9dded0da06b0b186ce...
Those files are not updated in any debian-packaged version at the moment, and each includes a necessary piece of this puzzle. From there, you will need to apply the additional change here: https://www.virtualmin.com/comment/809098#comment-809098
Hopefully that can help get you straightened out.
Submitted by sgrayban on Mon, 03/25/2019 - 16:34 Comment #71
This still isn't working on VM Pro even with the diff added. No PHP-FPM packages were found on this system. Is what I get when re-checking configuration.
NM I forgot to add the diff for php-lib.pl
I can confirm that VM Pro works with those changes.
The following PHP versions are available : 5.6.40 (/usr/bin/php-cgi5.6), 7.0.33 (/usr/bin/php-cgi7.0), 7.1.27 (/usr/bin/php-cgi7.1), 7.2.16 (/usr/bin/php-cgi7.2), 7.3.3 (/usr/bin/php-cgi7.3), 7.0 (mod_php)
The following PHP-FPM versions are available on this system : 7.2.16
Submitted by sgrayban on Mon, 03/25/2019 - 16:50 Comment #72
Whoops spoke to soon. Yes VM Pro finds fpm now but in Website Options you don't have the option to use FPM.
Does edit_phpmode.cgi need to be edited ?
Submitted by aschenbr on Sat, 03/30/2019 - 19:26 Pro Licensee Comment #73
I followed this and it worked for me @aschenbr - The changes I made in the referenced comment modified the version of php-lib.pl found here: https://github.com/virtualmin/virtualmin-gpl/blob/e1987a29dd4c88343ea5e6...
You'll also need the updated feature-web.pl - https://github.com/virtualmin/virtualmin-gpl/blob/9feb9dded0da06b0b186ce...
Those files are not updated in any debian-packaged version at the moment, and each includes a necessary piece of this puzzle. From there, you will need to apply the additional change here: https://www.virtualmin.com/comment/809098#comment-809098
Hopefully that can help get you straightened out.
Submitted by sgrayban on Sun, 03/31/2019 - 01:42 Comment #74
I made all those changes. Maybe there is a file in the VM Pro that needs to be changed still that isn't posted yet.
Submitted by genbushi on Thu, 04/04/2019 - 23:01 Comment #75
Patched a few Debian 9.x boxes as specified in this thread.
Result:
The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.3.3 (/usr/bin/php-cgi7.3)
The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.3.3
Submitted by sgrayban on Fri, 04/05/2019 - 21:35 Comment #76
But can you select the FPM version under Website Options ?
Submitted by genbushi on Sun, 04/07/2019 - 08:43 Comment #77
Yes, I was able to flop from FPM or FCGI, and from PHP 7.0.x or 7.3.x
Submitted by oMikR0n on Sun, 04/07/2019 - 09:33 Comment #78
Patched and fix also on debian 9.8! YAY!
Submitted by mikt on Sun, 04/07/2019 - 10:14 Comment #79
Just a short note if cli shows the version but web does not:
Restart your webmin server
I missed that :(
Submitted by draxius on Mon, 04/29/2019 - 01:28 Comment #80
For everyone who is following this thread, I submitted a pull request (which has already been merged into the master) to add the Debian-friendly code - https://github.com/virtualmin/virtualmin-gpl/commit/3e2475f1ca3712785635...
With any luck, this should be part of the packaged 6.07 release for all platforms, but that's in the hands of the devs now.
Submitted by Johnny73 on Tue, 04/30/2019 - 16:02 Comment #81
One more debian 9 system got multi php-fpm. thanks! By the way. how to make fsgi + php fpm. As people write that's the most performance solution now
Hi, I think i did something wrong. I replaced files php-lib and feature-web and can change between php versions, but the config file is not switched. I back to the original php version and all the config in php config disapeared.... Should i install virtualmin from scratch?
Submitted by adamjedgar on Thu, 06/13/2019 - 19:16 Pro Licensee Comment #83
the only change that i needed to make on the latest updates in debian and virtualmin was to edit the one file
php-lib.pl
as outlined by https://www.virtualmin.com/comment/808744#comment-808744after doing that then reckecking configuration in Virtualmin, I am now able to select different releases of fpm (ie 7.0-7.3).
I did notice that virtualmin authentic theme has thrown an error after doing this...(the error dissapeared before i could copy it), so I am not sure if that is related to this php fpm change or not?
Submitted by xillion on Thu, 06/20/2019 - 06:32 Pro Licensee Comment #84
Any update on 6.07 availablity?
Submitted by mikt on Thu, 08/01/2019 - 16:26 Comment #85
I am still not able to select fpm in 6.07 - am i doing something wrong or is it still not fixed after all those months?
Submitted by aschenbr on Thu, 08/01/2019 - 16:28 Pro Licensee Comment #86
Brutal still busted. i wish they would get their act together with this virtualmin, im ready to abandon after years of using them, as a paid customer.
Submitted by mikt on Thu, 08/01/2019 - 17:04 Comment #87
okay - what seems to work for me is:
No clue why this can not be fixed.
Submitted by aschenbr on Fri, 08/02/2019 - 00:46 Pro Licensee Comment #88
Actully i just deleted that line, i think i may be depreciated
php_fpm_version=7.x
and it works, such a waste of time for lazy code
Submitted by mikt on Fri, 08/02/2019 - 04:29 Comment #89
Not working for me - it is getting back with 7.2 if i delete it.
Submitted by aschenbr on Fri, 08/02/2019 - 09:23 Pro Licensee Comment #90
So for my instance Im only running 7.2.21, so it picks it up, but if you have multiple, you may have to put that in, I haven't been able to try that. And this is also on CentOS 7. Fyi.
Submitted by adamjedgar on Mon, 10/21/2019 - 06:52 Pro Licensee Comment #91
This is not completely fixed...whilst one can manually change to php-fpm versions, i have still encountered a problem in server templates.
Virtualmin>System Settings>Edit Server Template>default template>Edit Template Section>php options (dropdown) - php versions = highest available (the drop down list shows available versions 7.0, 7.1,7.2,7.3)
However, when i provision a new virtual server, it keeps setting php-fpm to version 7.0.
Shouldnt "highest available" mean the last release in the list...ie v7.3?
this means every time a virtual server gets provisioned, i have to manually go in and change it. A flaming nightmare to be honest!
Submitted by Jfro on Mon, 10/21/2019 - 07:01 Comment #92
Offtopic joking sorry. IF this is giving you already a.
A flaming nightmare
I guess it is easy for your partner to give you very nice dreams to. ;)
If you choose the version 7.3 in that dropdown does it work well then.
I'm not from virtalmin supprt!
Submitted by oMikR0n on Mon, 10/21/2019 - 09:58 Comment #93
Same here. Would be nice if we can also use FPM for multiple php versions
Submitted by adamjedgar on Mon, 10/21/2019 - 15:22 Pro Licensee Comment #94
php-fpm isn't changing at all, only php. when I go to virtualmin>services>php-fpm configuration, is still showing version 7.0 for new virtual servers. Only one of my virtual servers is 7.3...all the others 7.0 (so multiple versions is possible but the selector isn't working)
One thing I do note, if I recheck Virtualmin configuration, I get a number of "fixing port clash" lines, then any virtual server using php goes offline. I have to go into virtualmin>server configuration>website options and change php-fpm to fcgid and back again to bring them back online again (happens every time)...is this related to me having multiple fpm versions active on virtual servers?
Hey guys, I'm not sure why this would make a difference but the fix, as implemented above (and in version 6.0.8), has worked perfectly for me with any versions I've tried to use/add from php5.6, 7.0, 7.1, 7.3 & 7.3.
Now that 7.4 has just been released a few weeks ago, I added it to my system and did a "re-check", and it picks up 7.4 as a cgi option but it won't pickup it's FPM oddly enough.
The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.3.12 (/usr/bin/php-cgi7.3), 7.4.0 (/usr/bin/php-cgi)
The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.3.12
I confirmed that the following directories/files exist:
/etc/php/7.0/fpm/pool.d/www.conf
/etc/php/7.3/fpm/pool.d/www.conf
/etc/php/7.4/fpm/pool.d/www.conf
Which, from what I understand from the code above in php-lib.pl are the directories that it checks for? Line 1747:
DIR: foreach my $cdir ("/etc/php-fpm.d",
"/etc/php*/fpm/pool.d",
"/etc/php/*/fpm/pool.d",
"/etc/opt/remi/php*/php-fpm.d",
"/etc/opt/rh/rh-php*/php-fpm.d",
"/usr/local/etc/php-fpm.d")
Odd that 7.4 would not be detected when multiple other versions are and the naming of the folder is not odd or any different, just a version number change?
Any ideas??
Submitted by JamieCameron on Thu, 12/12/2019 - 22:04 Comment #96
The issue here is that Virtualmin in the current release doesn't know to look for PHP 7.4 at all. This will be fixed in the next version though.
Submitted by webberz on Tue, 12/17/2019 - 10:21 Comment #97
Tested on Debian 9, clean installs, latest Virtualmin 6.08 1) with apache -> it works 2) with ningx it does not work. I get the option to select and change the PHP version with FPM enabled but it reports "Failed to save PHP versions : The PHP version cannot be changed when in FPM mode"
Is support when using nginx being worked on?
Submitted by Bsara on Thu, 01/02/2020 - 10:40 Comment #98
Please, I try to change my PHP version and every time I try to change the PHP version I got. Failed to save PHP versions: The PHP version cannot be changed to any version except the default for Nginx websites. What should I do I need to change my PHP version? I run WordPress and Nginx, PHP FCGI
One year later, and the problem is not yet fixed.... https://www.virtualmin.com/comment/808744#comment-808744
What exactly doesn't work for you?
just misstyped a command and deleted a file. My fault. sorry
Submitted by IssueBot on Sat, 03/28/2020 - 14:42 Comment #102
Automatically closed - issue fixed for 2 weeks with no activity.
Submitted by SidedTech on Tue, 10/06/2020 - 12:25 Comment #103
Has this issue been fixed? Can I install multiple versions of PHP? I do not need to use 2 simultaneously, but what happens is when website start giving you warnings of old PHP, you want to switch the whole thing by going to the list, and picking new one, and automatically applying.
For example, all of my WordPress installs from 2015-16 were giving me 5.6 out of date errors, and I wanted to get them to 7.2, so I was hoping I could install PHP 7.2
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php7.2
php -v PHP 7.2.13-1+ubuntu16.04.1+deb.sury.org+1
and then go into Virtualmin PHP version, and switch, and have all sites switch versions automatically. Is this not possible? Do I still need to go into Apache and:
sudo a2enmod php7.2
apachectl -t
sudo service apache2 restart
and then test with
user@test:~# ls /etc/apache2/mods-enabled/php* /etc/apache2/mods-enabled/php7.2.conf /etc/apache2/mods-enabled/php7.2.load
or if I can just switch in Vmin menu under PHP Versions.
Then usually I just
You can tell which PHP version you are using by putting up a PHP Info page.
Then if you visit the page in the browser it should look something like this:
https://lwstatic-a.akamaihd.net/kb/wp-content/uploads/2019/01/phpinfo-mi...
If you had a site already up and running on the previous PHP version, test it out now and see if there are any issues. If your code isn’t compatible or showing errors, you can try to diagnose further or if you need the site back up right away you can downgrade the PHP version again by running the a2dismod and a2enmod commands to disable PHP 7.2 and then enable 7.0 or whichever previous version you had on the server then restart Apache again.
Some sites may now show an error saying a module is missing and can’t run, or if you are developing a new site and have a list of modules that are needed, then the next section can help you add new modules. Adding Modules to PHP 7.2
The switch to PHP 7.2 doesn’t automatically keep all the same modules from previous PHP versions. If you don’t need to compare the list to a previous PHP version then to install any basic modules you do need, first type the comannd below. But don’t press enter, if you press the TAB key twice you should get a list of available modules specific to 7.2::
@test:~# sudo apt-get install php7.2[tab][tab]
Example Output: php7.2 php7.2-enchant php7.2-mbstring php7.2-snmp php7.2-bcmath php7.2-fpm php7.2-mysql php7.2-soap php7.2-bz2 php7.2-gd php7.2-odbc php7.2-sqlite3 php7.2-cgi php7.2-gmp php7.2-opcache php7.2-sybase php7.2-cli php7.2-imap php7.2-pgsql php7.2-tidy php7.2-common php7.2-interbase php7.2-phpdbg php7.2-xml php7.2-curl php7.2-intl php7.2-pspell php7.2-xmlrpc php7.2-dba php7.2-json php7.2-readline php7.2-xsl php7.2-dev php7.2-ldap php7.2-recode php7.2-zip
This is not a complete list so you may need to look up how to install other modules you may need. You can type the modules you want, and you can add multiple in the same install command, like:
user@test:~# sudo apt-get install php7.2-opcache php7.2-mbstring php-memcached
If you did save the list of modules from a previous PHP version with the command earlier in the guide, you can save a list of the modules in PHP 7.2 and compare them with the previous version. Run:
php -m > /tmp/7.2.modulelist.txt
Then to compare it to the list that was created before, run:
user@test:~# diff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.txt 15,16d14 < mysqli < mysqlnd 21d18 < pdo_mysql 28d24 < soap 29a26
Or if you want a more visual way to compare the two lists, run:
user@test:~# vimdiff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.txt Run the vimdiff command to see the modules that are different from previous PHP versions.
Which will show a page like this in the terminal:
In this example, the various MySQL modules and soap show up on the list of 7.0 modules on the left but are missing from the 7.2 version on the right, and the sodium module is on 7.2 but wasn’t in 7.0.
So for this example, we can install the missing modules with:
user@test:~# sudo apt-get install php7.2-mysql php7.2-soap
After that installs, we can save an updated list of modules and can compare it again:
user@test:~# php -m > /tmp/7.2.modulelist.updated.txt diff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.updated.txt 29a30
Is that still necessary, or did we get it fixed? Sorry for longer question on closed topic but will help Google searches find Vmin Lol
According to our manual, you need these packages installed as well -
After installing new PHP version run Re-Check Configuration from System Settings.
No.