"Error al cargar bibliotecas compartidas:libjli.so:no se puede abrir el archivo de objeto compartido:No existe tal archivo o directorio" Error de 'java -version' en el inicio

El problema

"java -version" se cierra con el mensaje de error "error al cargar bibliotecas compartidas:libjli.so:no se puede abrir el archivo de objeto compartido:no existe tal archivo o directorio" al intentar iniciar la JVM.

Caso 1

El problema está ahí si se ejecuta con un usuario normal o si se ejecuta con el usuario root

$ java -version
[PATH_TO]/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Caso 2

El problema está ahí solo si lo ejecuta un usuario normal. No hay problema si se ejecuta bajo el usuario root.

Bajo un usuario normal:

$ java -version
[JAVA_HOME]/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Bajo raíz:

# [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

Solución para el Caso 1

O solo se copió el binario de Java en una carpeta (p. ej., /usr/bin/) sin copiar el resto de los directorios JRE o JDK, o simplemente se creó un enlace fijo del binario de Java en la carpeta (p. ej., /usr/bin/) .

# cp [JAVA_HOME]/jre/bin/java /usr/bin/

Si el binario del iniciador de Java no puede encontrar los archivos de JRE/JDK, no podrá iniciar la JVM. El libjli.so está vinculado dinámicamente al binario de Java. Es una de las primeras bibliotecas que el lanzador de Java intenta cargar. Se requiere el iniciador de Java para poder leer todas las bibliotecas asociadas de Java para poder iniciar correctamente.

Hay 2 formas de resolver esto:

Solución 1

Cree un enlace simbólico en lugar de un enlace fijo o una copia si desea llamar a Java desde la carpeta /usr/bin.

# sudo ln -s [path to the JRE's java binary] /usr/bin/java

Nota :Los sistemas Linux que admiten el comando "update-alternatives" deben usar la solución 2 a continuación en lugar de crear un enlace simbólico.

Solución 2

use el comando update-alternatives según la publicación a continuación para establecer la ruta java correcta.

El comando "java" no ejecuta la JVM que se ha instalado

Solución para el Caso 2

Hay 2 escenarios aquí:

Escenario 1

El "setcap El comando ” se ha utilizado para otorgar al binario de Java el permiso adecuado para otorgar derechos especiales a los usuarios sin privilegios. Por ejemplo, para abrir puertos inferiores a 1024:

# setcap cap_net_bind_service=+ep /bin/java

Al aumentar los privilegios de un ejecutable, el cargador de tiempo de ejecución (rtld), mejor conocido como ld.so, no se vinculará con bibliotecas en rutas que no sean de confianza. Esta es la forma en que se diseñó ld.so(1). Si es necesario ejecutar un ejecutable de este tipo, las rutas a las bibliotecas asociadas para el ejecutable elevado deben agregarse a las rutas de confianza de ld.so.

Escenario 2

El JDK/JRE se instaló con una cuenta de usuario diferente (por ejemplo, root) y los permisos de lectura mundial se eliminaron explícitamente solo de libjli.so o incluso de toda la estructura de directorios de JDK o JRE. Ejemplo:

# chmod -R o-r [JAVA_HOME]

Si el usuario que inicia Java no tiene permisos para leer la biblioteca libjli.so, Java fallará. Esto se debe a que libjli.so está vinculado dinámicamente al binario de Java. Java debe poder leer todas sus bibliotecas vinculadas dinámicamente para poder iniciarse correctamente.

Solución para el Escenario 1

Hay 2 soluciones aquí:

1. Elimine la capacidad del binario de Java nuevamente:

# setcap -r [JAVA_HOME]/bin/java

Verifique que java -version esté funcionando ahora:

$ [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

2. Cree un archivo como este, con la ruta a libjli.so:

$ cat /etc/ld.so.conf.d/java.conf
[JAVA_HOME]/jre/lib/amd64/jli

Nota :si usa un JRE de 32 bits, reemplace amd64 con i386.

Esto agregará esa ruta a la ruta de usuario de confianza que usará ld.so. Puede ser necesario para construir la memoria caché de tiempo de ejecución. Verifique si ld.so lo está viendo haciendo lo siguiente. Los comandos deben ejecutarse como root. Es posible que sea necesario reiniciar.

# ldconfig | grep libjli
libjli.so -> libjli.so
.......

Verifique que java -version esté funcionando ahora:

$ [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

Solución para el Escenario 2

Restaure los permisos de lectura para que el usuario pueda leer libjli.so y otros archivos de los directorios JDK/JRE. Por ejemplo:

# chmod -R o+r [JAVA_HOME]

Verifique que java -version esté funcionando ahora:

$ [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)