On Tue, 16 Jul 2024 at 08:01, Condor <condor@stz-bg.com> wrote:
[Tue Jul 16 07:12:17.358108 2024] [mpm_event:notice] [pid 1536:tid 1536]
AH00494: SIGHUP received. Attempting to restart
PHP Warning: Failed loading Zend extension 'opcache' (tried:
/usr/lib64/php/extensions/opcache (/usr/lib64/php/extensions/opcache:
cannot open shared object file: No such file or directory),
/usr/lib64/php/extensions/opcache.so
(/usr/lib64/php/extensions/opcache.so: cannot allocate memory in static
TLS block)) in Unknown on line 0
Does that file exist on the system? And if so, in which directory is it located?
/usr/lib64/php/extensions/opcache.so
On Tue, 16 Jul 2024 at 09:59, Condor <condor@stz-bg.com> 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?
Condor
3
On 2024-07-16 13:32, Martin Herrman wrote:
On Tue, 16 Jul 2024 at 09:59, Condor <condor@stz-bg.com> 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.