libgcc_s.so.1 must be installed for pthread_cancel to work for php -v

[cloudlinux]

When I am in cagefs of a user and run php -v is says:

k1999@cpanel1 [/var/log]# php -v

libgcc_s.so.1 must be installed for pthread_cancel to work

Aborted

I have done

yum provides "*/libgcc_s.so.1"

And they are installed.

I also have run

cagefsctl --addrpm libgcc.x86_64

cagefsctl --addrpm libgcc-4.4.7-11.el6.x86_64

cagefsctl --addrpm libgcc.i686

cagefsctl --addrpm libgcc-4.4.7-11.el6.i686

cagefsctl --force-update

And have look in in the user with:

k1999@cpanel1 [/var/log]# ls -lah /lib64/libgcc_s.so.1

lrwxrwxrwx 1 root root 28 Oct 31 08:36 /lib64/libgcc_s.so.1 -> libgcc_s-4.4.7-20120601.so.1*

k1999@cpanel1 [/var/log]# ls -lah /lib64/libgcc_s-4.4.7-20120601.so.1

-rwxr-xr-x 1 root root 89K Oct 15 00:48 /lib64/libgcc_s-4.4.7-20120601.so.1*

What am I missing/forgetting? And why get I this error again and again?

We are using cagefs with the phpselector

[bogdan.sh]

Hi,

that quite strange as libgcc_s should be available from CageFS inside (and actually it is available according to your post). I believe something is wrong with ldconfig and process do not search for it in right place.

As of now please do the following as user:

strace -f -s400 -o strace.log php -v

grep libgcc_s strace.log

And show us the output.

[cloudlinux]

Sorry for the late anwser:

I have runned it and got:

901492 open("/opt/xslt/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/tidy/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/libmcrypt/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/pcre/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/curlssl/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/xml2/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/pcre/lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/curlssl//lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/php_with_imap_client//lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/libmcrypt//lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/tidy//lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/opt/xslt//lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/usr/lib64/tls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/usr/lib64/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

901492 open("/lib64/libgcc_s.so.1", O_RDONLY) = 3

902370 writev(3, [{"libgcc_s.so.1 must be installed for pthread_cancel to work\n", 59}], 1) = 59

[laurens]

You can try this: Search for RLimitMEM inside: /usr/local/apache/conf/httpd.conf

Try to make the first number bigger, like

RLimitMEM 2345678
to
RLimitMEM 3345678

Reminder: this is not a indication how the numbers could look. Since it is pretty much always bigger, than this.

Then run this:

/usr/local/cpanel/bin/apache_conf_distiller --update
/usr/local/cpanel/bin/build_apache_conf
service httpd -k restart

And lets hope its fixed.

I suggest to recompile with easyapache before you do something, and do updates because you seem to have to many not found messages :/

[bogdan.sh]

Laurens, Tim is getting issues not from browser, but from regular console, it is not related to apache rlimits.

Tim, could you please show from cagefs inside this:

ls -la /lib64/libgcc_s.so.1

On my test machine its a symlink to real library file, and it exists, please check the same:

> # ls -la /lib64/libgcc_s.so.1
> lrwxrwxrwx 1 root root 28 Oct 31 09:52 /lib64/libgcc_s.so.1 -> libgcc_s-4.4.7-20120601.so.1*
>
> # ls -la /lib64/libgcc_s-4.4.7-20120601.so.1
> -rwxr-xr-x 1 root root 90880 Oct 14 16:22 /lib64/libgcc_s-4.4.7-20120601.so.1*

[cloudlinux]

Ok I have tried what you suggested:

cage@cpanel1 [~]# ls -la /lib64/libgcc_s.so.1

lrwxrwxrwx 1 root root 28 Oct 31 08:36 /lib64/libgcc_s.so.1 -> libgcc_s-4.4.7-20120601.so.1*

cage@cpanel1 [~]# ls -la /lib64/libgcc_s-4.4.7-20120601.so.1

-rwxr-xr-x 1 root root 90880 Oct 15 00:48 /lib64/libgcc_s-4.4.7-20120601.so.1*

It is the same as on your test system.

[bogdan.sh]

Indeed, it looks properly, actually everything looks properly but it does not works...

Really I have no more ideas, please create a support ticket so we could check server itself.

[cloudlinux]

> Bogdan wrote:
> Indeed, it looks properly, actually everything looks properly but it does not works...
>
> Really I have no more ideas, please create a support ticket so we could check server itself.

Ok i will do that. Bummer, I hope I could fixed it myself ;-)

[cloudlinux]

Ok I have found the error:

Ok I just disabled "Shell Fork Bomb Protection" and ran "/usr/sbin/cagefsctl --force-update".

I saw a lot of:
Removed file /var/cagefs/xx/xxxxx/etc/profile.d/limits.csh
Removed file /var/cagefs/xx/xxxxx/etc/profile.d/limits.sh

Then I check and the php -v is working again. I then re-enabled the "Shell Fork Bomb Protection" and run again "/usr/sbin/cagefsctl --force-update".

Now it is still working. So I think the error lies within the "Shell Fork Bomb Protection".

[bogdan.sh]

Looks you are right, that could be it.

As limits.csh and limits.sh were removed with cagefsctl --force-update they should be add back after you enable it. However you may also execute cagefsctl --update-etc to update just etc and be sure limits will be processed.

By the way as I know shell fork bomb writes also to this files: /etc/bashrc and /etc/profile .