RHEL server Yum dependencies not working

Question

I have a redhat server that isnt resolving dependencies correctly.

I want to install httpd via yum "yum install httpd" and it installs correctly, but when i go to start httpd I get the following error:

/sbin/service httpd restart

Stopping httpd:                                            [FAILED]
Starting httpd: /usr/sbin/httpd: error while loading shared libraries: libaprutil-1.so.0: cannot open shared object file: No such file or directory
                                                           [FAILED]

It is missing the dependency for apr-util package.

Weirdly the i386 package is installed and not the x86_64 package. Can anyone shed any light on why the dependencies might not be resolved correctly?

ldd /usr/sbin/httpd
    libm.so.6 => /lib64/libm.so.6 (0x00002b02370db000)
    libpcre.so.0 => /lib64/libpcre.so.0 (0x00002b023735e000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b023757a000)
    libaprutil-1.so.0 => not found
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b0237793000)
    libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002b02379cb000)
    liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002b0237c06000)
    libdb-4.3.so => /lib64/libdb-4.3.so (0x00002b0237e14000)
    libexpat.so.0 => /lib64/libexpat.so.0 (0x00002b0238109000)
    libapr-1.so.0 => not found
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b023832c000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002b0238547000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b023874c000)
    libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b0238aa3000)
    /lib64/ld-linux-x86-64.so.2 (0x00002b0236ebe000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b0238ce9000)
    libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002b0238eff000)
    libssl.so.6 => /lib64/libssl.so.6 (0x00002b0239118000)
    libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b0239364000)
    libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b02396b6000)
    libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b02398e4000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b0239b79000)
    libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b0239d7c000)
    libz.so.1 => /usr/lib64/libz.so.1 (0x00002b0239fa1000)
    libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b023a1b5000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b023a3be000)

yet this is the i386 package

apr-util-1.2.7-11.el5.i386 : Apache Portable Runtime Utility library
Repo        : installed
Matched from:
Filename    : /usr/lib/libaprutil-1.so.0

UPDATE: Just to update, I am hosting my own repo on a cobbler server also, but that was created correctly and im not sure if this would cause any problems with dep solving?

UPDATE2: I have changed the debug level to 10 to see what i get via yum, here is the output.

im pretty sure there should be an entry other than none, but not sure what it should be...

Resolving Dependencies
Running "preresolve" handler for "security" plugin
--> Running transaction check
---> Package httpd.x86_64 0:2.2.3-31.el5 set to be updated
Checking deps for httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('initscripts', 'GE', ('0', '8.36', None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libc.so.6(GLIBC_2.2.5)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libpthread.so.0(GLIBC_2.2.5)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('rtld(GNU_HASH)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/etc/mime.types', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/bin/bash', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/bin/sh', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('textutils', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libm.so.6(GLIBC_2.2.5)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/sbin/chkconfig', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/bin/rm', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/bin/sh', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/bin/mv', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/usr/share/magic.mime', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/usr/sbin/useradd', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/usr/bin/find', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libcrypt.so.1(GLIBC_2.2.5)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('sh-utils', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libc.so.6(GLIBC_2.3.4)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libc.so.6(GLIBC_2.4)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('gawk', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libc.so.6(GLIBC_2.3)(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('/bin/mktemp', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libc.so.6()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libpcre.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libdb-4.3.so()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libcrypto.so.6()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libexpat.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libselinux.so.1()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libm.so.6()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libssl.so.6()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('liblber-2.3.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libdl.so.2()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libaprutil-1.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libz.so.1()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libcrypt.so.1()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libapr-1.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libpthread.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
looking for ('libldap-2.3.so.0()(64bit)', None, (None, None, None)) as a requirement of httpd.x86_64 0-2.2.3-31.el5 - u
--> Finished Dependency Resolution
Dependency Process ending
Depsolve time: 0.811

Solution 1

I have tracked down this issue to another package advertising that it can resolve the dependency for libapr. So when http said it needed libapr, this badly written package said it could fulfil the library need so got installed rather than the proper redhat libapr package. I have organised for the developer to be beaten

Solution 2

I'm not sure why you wouldn't get the proper dependencies (without knowing the exact RHEL version, it's hard to double-check info). There are multiple cases where you might need or have both the i386 and x86_64 versions of the same package installed. It's also possible to run into quirks or bugs (though I've seen it relatively rarely) where the architecture specific packages screw up dependencies.

You should be able to install the x86_64 version with yum install apr-util-1.2.7-11.el5.x86_64.

Comments

[Ignacio Vazquez-Abrams]

package-cleanup --problems says?

[JimB]

Have you tried installing the missing dependency? yum install apr-util.x86_64

[Aaron Copley]

Could we see your /etc/yum.conf?

[Tony]

@JimB Yes i can install manually, but it should pick it up automatically.

[Tony]

@Aaron, its a bog standard yum.conf

[Ignacio Vazquez-Abrams]

It's not supposed to help, it's supposed to show you what's wrong. You're still going to have to push buttons afterwards to fix it.

[Tony]

@IgnacioVazquez-Abrams, yes, sorry probably worded my response incorrectly... i ran it, nothing came back, all was ok, no errors.

[Aaron Copley]

Does it fail to resolve any dependency for any install? Or just apr-utils for httpd?

[hilcharge]

yum whatprovides *libaprutil-1.so will show what package is providing the library

[Tony]

Hi, thanks for the reply, but it should and has installed the apr dependency automatically when you do a yum install httpd. Im just not sure why it would install the i386 version and not the x68_64 version, when its a 64bit system?

[demonkoryu]

Yeah, I'm really not sure why it would happen. Maybe something else was installed that listed the i386 version as a dependency? So it got installed for that, and then httpd screwed up and assumed that since a version of it was installed, everything was good (without checking that it was the x86_64 version)? I'm just speculating, and I don't really know. I'd be curious what would happen if you removed both and then reinstalled httpd. If it didn't pull in the right dependency from that, it'd be worth further investigation.

[Ignacio Vazquez-Abrams]

It might be helpful to mention the package here so that others can avoid it as well.

[Tony]

Its a custom internal package, so others shouldnt have this issue. The developer responsable has been moved to tea making duties :)