Wrong Version Of Php
It’s been a while since I updated to php72 on this machine and there is some setting I must have forgotten. Apache, root and a user automatically get php72 when I run php in a terminal window, however, a php script picks up the wrong version of php, ie php54 and the version of php in /usr/bin/php is indeed version 5.4.
I have googled without finding the answer but how do I make sure /all/ processes use php72 rather than the default 54 in CentOS 7? Surely there must be a better way than overwriting /usr/bin/php. What have I forgotten to do?
Thank you.
11 thoughts on - Wrong Version Of Php
I would find out which package it indeed belongs to:
rpm -qf /usr/bin/php
I would also find out the name or package that brings PHP 7.2, like:
rpm -qa | grep php
and then list all files in that package, say, if it is php-7.2, then
rpm -ql php-7.2 | less
You will see the mame of executable to invoke php72, in the list above could be something like
/usr/bin/php72
Note, I do not run php on Linux anymore, but the above are educated guesses how multiple concurrent packages layed out to not interfere with each other.
Valeri
You can’t/shouldn’t do that. The point of the Enterprise OS is that versions are consistent throughout the lifetime of the OS, so packages don’t change the default versions because things may break because something is expecting PHP 5.4 and not 7.2.
If you have an application that needs PHP 7.2, then change the way it is invoked so it runs using ‘php72’ instead of just ‘php’.
Now, in all honesty I suspect that changing the default version of PHP
isn’t going to break many things at the system level; at least not in the same way as it would if you changed the default python to python3. But it is something that may save you problems in the future.
P.
My thought exactly, however, I believe I made at least some of the changes required for new terminal sessions to use php72 rather than the default php54 but for some reason this script uses php54.
The script starts:
#!/usr/bin/env php
I know I can always change this to use the already installed php72 but there must be some other change I forgot to make on my system??
—-Original Message—
I read up on alternatives but it seems to require a2dismod and a2enmod which apparently are Debian solutions. I did try:
update-alternatives –set php /opt/rh/rh-php72/root/usr/bin/php
but that did not make any difference to this script. It must be reading the location of php from somewhere else.
Surely there must be a system-wide way of forcing all uses of php to use php72 rather than the default php54 that I still want to keep on the system?
Problem solved, there was a configuration file for this app that specifically referenced /usr/bin/php, ie the default version php54. I am now able to run the script in a terminal window but creating a systemd unit still does not work and still references the default version php54.
Googling I found this that suggests serviced works differently with respect to eg php installed from Software Collections:
https://access.redhat.com/solutions/527703
Is anyone familiar with this?
Am 22.06.20 um 22:27 schrieb H:
If you want it in the terminal with php72 then switch to that context with (temporarily for this session):
scl enable rh-php72 bash
if I am syntactically wrong about the collection name check it with
scl –list
Thanks Leon! As usually I can tell myself: you learn something every day.
Valeri
I have that already but that only applies to new terminal sessions. The current issue is that systemd does not seem to pick up a global configuration of using php72 rather than the default php54.
See https://access.redhat.com/solutions/527703
Am 23.06.20 um 17:35 schrieb H:
I do not known what exactly you are trying but for scripts you could pass the php binary with full path or use a shebang like
#!/opt/rh/rh-php72/root/usr/bin/php
Fixed, I realized I can specify the php executable in the systemd unit.