Monthly maintenance fails: [apnscp/php-filesystem-template : Link system extension directory to socket]

Support
1

Monthly system health report fails every month, always on the same task:

TASK [apnscp/php-filesystem-template : Link system extension directory to socket] *** fatal: [localhost]: FAILED! => {"changed": false, "gid": 0, "group": "root", "mode": "0777", "msg": "src file does not exist, use \"force=yes\" if you really want to create the link: /.socket/php/usr/lib64/20210902", "owner": "root", "path": "/home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20210902", "size": 51, "src": "/.socket/php/usr/lib64/20210902", "state": "link", "uid": 0}

Current system state:

# ls -l /usr/lib64/2*

lrwxrwxrwx 1 root root 51 Aug 15 12:23 /usr/lib64/20131226 -> /.socket/php/multiphp/native/5.6/usr/lib64/20131226
lrwxrwxrwx 1 root root 51 Mar 27 10:37 /usr/lib64/20190902 -> /.socket/php/multiphp/native/7.4/usr/lib64/20190902
lrwxrwxrwx 1 root root 51 Mar 27 10:30 /usr/lib64/20200930 -> /.socket/php/multiphp/native/8.0/usr/lib64/20200930
lrwxrwxrwx 1 root root 51 Sep  1 03:47 /usr/lib64/20210902 -> /.socket/php/multiphp/native/8.1/usr/lib64/20210902
lrwxrwxrwx 1 root root 51 Mar 27 10:46 /usr/lib64/20220829 -> /.socket/php/multiphp/native/8.2/usr/lib64/20220829

# ls -l /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/2*

lrwxrwxrwx 1 root root 51 Aug 15 12:23 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20131226 -> /.socket/php/multiphp/native/5.6/usr/lib64/20131226
lrwxrwxrwx 1 root root 51 Mar 27 10:37 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20190902 -> /.socket/php/multiphp/native/7.4/usr/lib64/20190902
lrwxrwxrwx 1 root root 51 Mar 27 10:30 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20200930 -> /.socket/php/multiphp/native/8.0/usr/lib64/20200930
lrwxrwxrwx 1 root root 51 Sep  1 03:47 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20210902 -> /.socket/php/multiphp/native/8.1/usr/lib64/20210902
lrwxrwxrwx 1 root root 51 Mar 27 10:46 /home/virtual/FILESYSTEMTEMPLATE/siteinfo/usr/lib64/20220829 -> /.socket/php/multiphp/native/8.2/usr/lib64/20220829

# ls -l /.socket/php/usr/lib64/

total 0
drwxr-xr-x 2 root root 299 Sep  1 03:30 build

# cpcmd scope:get php.multi

'8.1': system
'8.0': native
'7.4': native
'8.2': native
'5.6': native

# cpcmd scope:get php.version

8.1

# php -v

PHP 8.1.23 (cli) (built: Sep  1 2023 03:29:30) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.23, Copyright (c) Zend Technologies
    with the ionCube PHP Loader v12.0.5, Copyright (c) 2002-2022, by ionCube Ltd.
    with Zend OPcache v8.1.23, Copyright (c), by Zend Technologies

# cpcmd misc_cp_version

revision: fe41ead6f8212b4982f57c27bd455ddc22d19c4e
timestamp: 1693411074
ver_maj: 3
ver_min: 2
ver_patch: 38
ver_pre: ''
dirty: false
debug: false

Temp workaround

This can be resolved by running
upcp -sbf php/install
upcp -sb apnscp/php-filesystem-template-
upcp -sb

But I’d like to know what the issue is that’s causing it to fail every month, and how I can go about fixing it for good. I see a related issue here but that looks like a one-off solution, rather than preventing this re-occurrence.

2

PHP 8.1 is your system PHP, which would use /usr/lib64/20210902 as a directory rather than symlink into /.socket/php/multiphp, which is reserved for multiPHP relocations. This looks similar to Running PHP via CLI after switching PHP versions shows some warnings. Broken symlink? - #3 by msaladna.

You began with a version other than 8.1 as the system PHP interpreter, then changed to 8.1 How did you change the version, using php.multi Scope or modifying the php_multiphp Bootstrapper variable directly?

apnscp/php-filesystem-template would be skipped on account of the trailing hyphen that doesn’t resolve to a valid role in bootstrap.yml.

upcp -sb is the same as a monthly integrity check.

3

Interesting. I saw that thread, but didn’t think it applied in this particular case - I don’t believe I started with anything other than 8.1 as the system interpreter. This install is only a couple of months old (which I think used 8.1 as the default) and I haven’t intentionally or knowingly tinkered with PHP versions other than the initial installation of other versions for multi PHP. There may well have been user error at this point, though. Looking back through history, I see the following:

cpcmd scope:set cp.bootstrapper php_multiphp '[7.4,8.0,8.1,8.2]'

So I’m guessing that including 8.1 was the mistake here, and should resolve with

cpcmd scope:set php.multi '[8.1:false]' - ?

Thanks!
W.

(No idea where I picked up that trailing hyphen in upcp -sb apnscp/php-filesystem-template-, that obviously does nothing of any use (although no error, which I guess I might expect). Running it without the hyphen does just repeat the gripe about symlinks, so ignore that part).

4

Correct. Rule of thumb: if a Scope exists, use that instead of modifying it directly. Scopes provide additional sanity checks to avoid potential erroneous configuration.

cpcmd scope:list provides a list of all Scopes. cpcmd scope:info NAMESPACE.NAME would give information on the named Scope within the namespace, e.g. cpcmd scope:info php.multi for php.multi used to manage multiPHP versions.

5

Marvellous, sorted. Beginner’s ignorance - dive in first, RTFM when things go wrong.
Thanks old chap.

1 Like