Problems restarting Apache Server

Question

Well, I'm having some problems restarting my Apache Server. I modified the ulimit on the server but I'm failing to restart httpd; I'm running the server on CentOS 5.8 x64 . The output from httpd -V:

Server version: Apache/2.2.3
Server built:   Jan 10 2013 08:19:28
Server's Module Magic Number: 20051115:3
Server loaded:  APR 1.2.7, APR-Util 1.2.7
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture:   64-bit

The error I'm getting when running /sbin/service httpd restart (I'm not going to print the hall output):

Syntax error on line 210 of /etc/httpd/conf/httpd.conf: 
Syntax error on line 6 of /etc/httpd/conf.d/php.conf: 
Cannot load /etc/httpd/modules/libphp5.so into server: libidn.so.11: 
wrong ELF class: ELFCLASS32

I googled this error and tried to dig for the problem. What I found is that libphp5.so is 64-bit architecture whilst libidn.so.11 is 32-bit. Normally, as I know, there shouldn't be a problem using 32-bit programs on 64-bit architecture, but in this case there's 32-bit library used in 64-bit program(****See this related question **).

I tried to install the 64-bit version of the library but what I could find, for my OS( centOS 5.8 ) is the libidn_x86_64 version, which is again on 32-bit.

Programs installed on server:

squid - Proxy
ffmpeg - for video streaming
csf-lfd -> firewall
Apache

Any help on finding the problem is appreciated!

Answer 1

Since the version of libidn in CentOS 5.1 is the same as in 5.9 (indeed it's the same file), it's probably a safe bet that it will install in 5.8

could find, for my OS(centOS 5.8) is the libidn_x86_64 version, which is again on 32-bit.

No, the name implies it's the 64 bit version - if it contains a 32 bit object file, then something has gone way wrong - further, given the wide usage of CentOS and that libidn is required for all sorts of things, I'm sure someone would have noticed by now if the rpm contained the wrong file.

You might want to spend some time thinking about how your server got into this state. It shouldn't have been possible to install/upgrade the PHP from Centos respoitories with the right dependencies in place (unless you forced it to ignore them).