Resolving “libjli.so: cannot open shared object file” Error in Java on RHEL5 64-bit Systems


3 views

When encountering the libjli.so error on RHEL5 with Java 1.6.0_16, the key observation is that root can execute Java programs while regular users cannot. This typically indicates one of three scenarios:

// Sample error output:
$ java -version
Error: could not find libjli.so
Error: could not find Java SE Runtime Environment.

First, let's verify the actual library locations:

# As root:
find / -name libjli.so 2>/dev/null
# Typical locations:
/usr/java/jdk1.6.0_16/jre/lib/amd64/jli/libjli.so
/usr/java/jre1.6.0_16/lib/amd64/jli/libjli.so

The most common fix involves checking these elements:

# 1. Verify symlinks (common in RHEL Java installations)
ls -l /usr/java/default
ls -l /etc/alternatives/java

# 2. Check directory permissions
namei -l /usr/java/jdk1.6.0_16/jre/lib/amd64/jli/libjli.so

# 3. Alternative library path setting
export LD_LIBRARY_PATH=/usr/java/jdk1.6.0_16/jre/lib/amd64/jli:$LD_LIBRARY_PATH

Even with SELinux disabled, residual contexts might cause issues:

# Check and reset SELinux contexts
ls -Z /usr/java/jdk1.6.0_16/jre/lib/amd64/jli/libjli.so
restorecon -v /usr/java/jdk1.6.0_16/jre/lib/amd64/jli/libjli.so

For enterprise environments, create a conf file:

# /etc/ld.so.conf.d/java.conf
/usr/java/jdk1.6.0_16/jre/lib/amd64
/usr/java/jdk1.6.0_16/jre/lib/amd64/jli

# Then run:
ldconfig

Create a test script to diagnose the issue:

#!/bin/bash
echo "Java version test:"
/usr/bin/java -version 2>&1 || echo "Failed"

echo "Library path check:"
ldd $(which java) | grep jli

echo "Permission check:"
stat -c "%a %U:%G %n" /usr/java/jdk1.6.0_16/jre/lib/amd64/jli/libjli.so

When working with Java 1.6.0 update 16 on 64-bit RHEL5, you might encounter a perplexing situation where root can execute Java programs flawlessly, while regular users get hit with:

error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

This typically happens because Java's dynamic linker can't locate the libjli.so library, which is part of the Java Runtime Environment (JRE). The library exists in the JRE directory, but the system isn't looking in the right places.

Here are several approaches to resolve this issue:

1. Update ld.so.conf

The most permanent solution is to add Java's library path to the system's library configuration:

# As root
echo "/usr/java/jdk1.6.0_16/jre/lib/amd64" >> /etc/ld.so.conf
ldconfig

2. Set LD_LIBRARY_PATH Properly

For temporary or user-specific solutions, set the environment variable correctly:

export LD_LIBRARY_PATH=/usr/java/jdk1.6.0_16/jre/lib/amd64:$LD_LIBRARY_PATH

3. Symbolic Link Creation

Create symlinks in standard library directories:

# As root
ln -s /usr/java/jdk1.6.0_16/jre/lib/amd64/libjli.so /usr/lib64/
ldconfig

After applying any solution, verify with:

ldconfig -p | grep libjli

You should see output similar to:

libjli.so (libc6,x86-64) => /usr/lib64/libjli.so

If you're launching a Java application, you can specify the library path directly:

java -Djava.library.path=/usr/java/jdk1.6.0_16/jre/lib/amd64 -jar your_app.jar
  • Always adjust paths according to your actual Java installation directory
  • The amd64 directory might be named differently on some systems
  • Consider updating to a newer Java version if possible