Posts tagged Common Issues

Subversion won’t install

0
1 year ago
by dennis in , ,

Hello readers!

Below is another issue I’ve seen a few times now and I figured it’s worth writing a post about.

Situation: Client cannot install subversion or another binary on his dedicated or VPS server via yum. They get an error such as:

subversion-1.4.2-4.el5_3.1.x86_64 from base has depsolving problems
--> Missing Dependency: perl(URI) >= 1.17 is needed by package  subversion-1.4.2-4.el5_3.1.x86_64 (base)
subversion-1.4.2-4.el5_3.1.i386 from base has depsolving problems
--> Missing Dependency: perl(URI) >= 1.17 is needed by package  subversion-1.4.2-4.el5_3.1.i386 (base)
Error: Missing Dependency: perl(URI) >= 1.17 is needed by package  subversion-1.4.2-4.el5_3.1.i386 (base)
Error: Missing Dependency: perl(URI) >= 1.17 is needed by package  subversion-1.4.2-4.el5_3.1.x86_64 (base)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest

To repair this, you have to install perl-URI but it really doesn’t give many details as to how. To fix this on CentOS 5.6 just do the following:

wget  http://mirror.centos.org/centos-5/5.6/os/x86_64/CentOS/perl-URI-1.35-3.noarch.rpm
rpm -ivh perl-URI-1.35-3.noarch.rpm

Then retry the installation via yum for subversion. Please note, the wget link changes depending on CentOS version. For Centos 5.5:

wget  http://mirror.centos.org/centos-5/5.5/os/x86_64/CentOS/perl-URI-1.35-3.noarch.rpm
rpm -ivh perl-URI-1.35-3.noarch.rpm

And for CentOS 5.4:

wget http://mirror.centos.org/centos-5/5.4/os/x86_64/CentOS/perl-URI-1.35-3.noarch.rpm
rpm -ivh perl-URI-1.35-3.noarch.rpm

Thank you all for reading and I hope this helps everyone solve another common issue more quickly and efficiently.

Common Issues – Maxed out Apache Connections

0
3 years ago
by dennis in , , ,

Hello everyone!

This week in “Common Issues”, we will be discussing the ever common “ran out of connections” issues many clients with very big websites see daily. This problem is a fairly simple solution but it is a easily missed one that many technicians don’t fully complete and leave half done. The first step is to check to ensure that the client is indeed running out of connections and that the error isn’t coming from some other place. The best way to discover if they are out of connections is by doing the following command:

/etc/init.d/httpd status

If you see no periods (.) and all letters in the status line, then the client is indeed out of connections. To increase it, firstly, we need to make sure they are using Apache 2.2 or higher. You can check this by looking at the top of the last command and checking the version mentioned. If it is greater than 2.0 then we can go on and make the change needed:

root@server [~]# /etc/init.d/httpd status
Apache Server Status for localhost
Server Version: Apache/2.2.13 (Unix) mod_ssl/2.2.13
....

The change itself, is very easy to make but requires two steps. Step one is to open up /usr/local/apache/conf/httpd.conf and make the following additions (I make them typically right after the top comment in the file:

ServerLimit NEW_MAX_CONNECTIONS
MaxClients NEW_MAX_CONNECTIONS

Where NEW_MAX_CONNECTIONS is the new max connections level you would like. Now step 1 is complete. Step 2 is incredibly important as well. You must run the following command to distill your changes to the file:

/usr/local/cpanel/bin/apache_conf_distiller --update

Without running that command, your changes will not be distilled and the next time apache is rebuilt, your changes will be lost. Finally, lets restart Apache and run status again to see if the change is committed. If you see more lines then previously, you now have more allowed connections!

Thank you for reading and stay tuned!

Go to Top