Re: cannot allocate memory in static TLS block
Condor <[email protected]>
| Newsgroups | gmane.comp.php.general |
|---|---|
| Message-ID | <[email protected]> |
On 2024-07-16 13:32, Martin Herrman wrote: > On Tue, 16 Jul 2024 at 09:59, Condor <[email protected]> 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.