Here’s my results from your steps. Note this machine was built with PHP 7.0 instead of 8.2.
# Verify system PHP version 7.0
cpcmd php:version
cpcmd scope:set cp.bootstrapper php_multiphp '[7.4,7.0]'
upcp -sb php/multiphp
Results:
# ls -l /usr/lib64/20*
# 7.0
lrwxrwxrwx 1 root root 51 Aug 28 16:45 /usr/lib64/20151012 -> /.socket/php/multiphp/native/7.0/usr/lib64/20151012
# 7.4
lrwxrwxrwx 1 root root 51 Aug 28 16:42 /usr/lib64/20190902 -> /.socket/php/multiphp/native/7.4/usr/lib64/20190902
# ls -l /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20*
lrwxrwxrwx 1 root root 51 Aug 28 16:45 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20151012 -> /.socket/php/multiphp/native/7.0/usr/lib64/20151012
lrwxrwxrwx 1 root root 51 Aug 28 16:42 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20190902 -> /.socket/php/multiphp/native/7.4/usr/lib64/20190902
Do you see a different module layout in /home/virtual/FILESYSTEMTEMPLATE versus what’s in the account’s vfs? If so, it’s due to OverlayFS caching dentries. In order for a directory entry to fully update, all open file handles must be released to it. Sometimes you can get away with cpcmd admin:kill-site siteXX ; cpcmd -d siteXX file:purge to terminate all processes on the site, then force OverlayFS to dump its cache.
Additionally, in this situation 8.2 shouldn’t be built as multiPHP because it duplicates system PHP. Use `php.multi’ Scope to set these versions:
# Add 8.1
cpcmd scope:set php.multi 8.1
# Remove 8.0
cpcmd scope:set php.multi '[8.0:false]'
There are additional checks in the Scope to prevent building a system PHP version as multiPHP, plus it merges results into php_multiphp.