On 06/22/2020 07:49 PM, H wrote: > On 06/22/2020 05:41 PM, Phoenix, Merka wrote: >> ----Original Message----- >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of H >> Sent: Monday, 22 June, 2020 14:31 >> To: centos at centos.org >> Subject: Re: [CentOS] Wrong version of php >> >>>> On 06/22/2020 05:21 PM, Pete Biggs wrote: >>>> 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? >>>>>> >>>>> 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?? >> -- >> Please see/read the man page for /etc/alternatives. This feature addresses what you would like to do. >> >> https :// linux. die. net /man/8/alternatives >> >> The alternatives system and the system administrator together determine which actual file is referenced by this generic name. For example, if the text editors ed(1) and nvi(1) are both installed on the system, the alternatives system will cause the generic name /usr/bin/editor to refer to /usr/bin/nvi by default. The system administrator can override this and cause it to refer to /usr/bin/ed instead, and the alternatives system will not alter this setting until explicitly requested to do so. >> >> The generic name is not a direct symbolic link to the selected alternative. Instead, it is a symbolic link to a name in the alternatives directory, which in turn is a symbolic link to the actual file referenced. This is done so that the system administrator's changes can be confined within the /etc directory: the FHS (q.v.) gives reasons why this is a Good Thing. >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > 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? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos 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?