On 2024-07-16 13:32, Martin Herrman wrote:
On Tue, 16 Jul 2024 at 09:59, Condor <condor@xxxxxxxxxx> wrote:
Yes, it exists into directory:
# ls -la /usr/lib64/php/extensions/opcache.so
-rwxr-xr-x 1 root root 1066544 Jul 5 22:38
/usr/lib64/php/extensions/opcache.so*
# ldd /usr/lib64/php/extensions/opcache.so
linux-vdso.so.1 (0x00007fc7de0f7000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fc7ddf85000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc7ddc00000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc7de0f9000)
The same with intl.so
# ls -la /usr/lib64/php/extensions/intl.so
-rwxr-xr-x 1 root root 588264 Jul 5 22:38
/usr/lib64/php/extensions/intl.so*
# ldd /usr/lib64/php/extensions/intl.so
linux-vdso.so.1 (0x00007fe17bc05000)
libicuio.so.74 => /usr/lib64/libicuio.so.74
(0x00007fe17bb26000)
libicui18n.so.74 => /usr/lib64/libicui18n.so.74
(0x00007fe17b800000)
libicuuc.so.74 => /usr/lib64/libicuuc.so.74
(0x00007fe17b400000)
libicudata.so.74 => /usr/lib64/libicudata.so.74
(0x00007fe179600000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6
(0x00007fe179200000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe17b717000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fe17b6ea000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe179000000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe17bc07000)
Are you running apparmor or SELinux that could block access?
The files are world readable, but does the user that runs apache/php
have access to the directory structure?
No, the OS does not use apparmor or SELinux. It's a Slackware. All
directory permissions is fines,
otherwise the Apache won't run on first start.
The problem it's not in the physical access to modules, it's something
else but I have no idea how to debug it or start trace it.
