Robin's questions

I am doing a system wide yum update on RHEL 5.5 and the IUS EPEL repository is throwing a missing dependency error:

php53-mcrypt-5.3.3-4.ius.el5.x86_64 from installed has depsolving problems
--> Missing Dependency: php53-common = 5.3.3-4.ius.el5 is needed by package php53-mcrypt-   5.3.3-4.ius.el5.x86_64 (installed)
Error: Missing Dependency: php53-common = 5.3.3-4.ius.el5 is needed by package php53-mcrypt-5.3.3-4.ius.el5.x86_64 (installed)

Is there is a way to run YUM update against all the other repositories ignoring the IUS EPEL repo to skip this dependency issue?

Clarification

I am trying to install the updates from the Redhat Network only. I cannot find the repo name so I am unable to do something like sudo yum --disablerepo=* --enablerepo=rhel update as the version of yum I am using does not support multiple repositories listed after --disablerepo.

Update

My temporary workaround is to run sudo yum --exclude=php53* update. I am convinced that there is a better way. This better way includes fixing the actual problem, so I filed a bug with the IUS Community Project as well.

Update #2

Looks like I found the issue with the dependency. I still think there should be a viable workaround.

Thanks!

I have two httpd servers running PHP on RHEL 5.7. Initially I was sharing PHP sessions between the servers using a common NFS share that was hosted on a third server. This was causing slow downs and eventually hangups on the httpd servers.

What is the best practice for sharing PHP session data between multiple httpd front end servers?

The vendor is recommending that I leverage load balancing connection persistence via a cookie or source IP, but I am concerned that a failure in one of the httpd servers will cause users to lose their session data and be logged out (for example).

Thoughts?

Thanks!

I am running the following on a Dell R610 (Quad core & 12GB RAM): Red Hat Enterprise Linux Server release 5.5 httpd 2.2.3 PHP 5.1.6

The web application running on this server is randomly leaking memory. Since the application is fairly big I have spent today trying to come up with a way to profile or trace the culprit script. The best tool I have so far is strace using strace -p PID -tt -o trace4.log -s 256. Unfortunately the memory usage can jump from 20m to 791m in a matter of seconds so running strace on the culprit process does not yield anything useful.

I tried starting httpd using strace strace -f -o trace_all.log /etc/init.d/httpd start, but unfortunately this causes extreme lag and unresponsiveness since the site receives fairly high traffic.

I understand that it is not best practice to debug in the production environment, but I am trying to narrow down what page and/or script is causing this issue and have been unable to replicate the problem when testing in the development environment

Any suggestions would be greatly appreciated.