Problema al iniciar Java en Debian: "error al cargar bibliotecas compartidas: libjli.so"

Estoy tratando de lanzar Java:

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

$ ldd /usr/lib/jvm/java-6-openjdk/jre/bin/java
        linux-gate.so.1 =>  (0xb779f000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7780000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7767000)
        libjli.so => /usr/lib/jvm/java-6-openjdk/jre/bin/../lib/i386/jli/libjli.so (0xb7762000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb775e000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7603000)
        /lib/ld-linux.so.2 (0xb77a0000
$ ls /usr/lib/jvm/java-6-openjdk/jre/bin/../lib/i386/jli/
libjli.so

Pero Java funciona bajo la raíz:

$ sudo java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~lenny1)
OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)

UPD:

/ usr / lib / jvm / java-6-openjdk / jre / bin / java es en realidad mi comando java:

$ type java
java is hashed (/usr/bin/java)
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Jul 14 10:15 /usr/bin/java -> /etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 40 Jul 14 10:36 /etc/alternatives/java -> /usr/lib/jvm/java-6-openjdk/jre/bin/java

UPD2:

También he intentado configurar la RUTA raíz:

$ sudo su
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# exit
$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ java -version
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

UPD3:

Estoy intentado:

# comm -3 <(declare | sort) <(declare -f | sort)

debajo de la raíz Pero no hay variables de entorno utilizables para Java.

UPD4:

strace -f java -versionresultado: http://dumpz.org/67368/

open("$ORIGIN/../lib/i386/jli/tls/i686/sse2/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

El ejecutable que está ejecutando busca bibliotecas en una ruta de acceso además de la ruta de búsqueda normal de la biblioteca. El camino aquí es $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Normalmente $ORIGINdebería ser reemplazado por la ubicación del ejecutable, aquí /usr/lib/jvm/java-6-openjdk/jre/bin.

Aquí, $ORIGINno está siendo reemplazado. La función está desactivada en ejecutables que se ejecutan con privilegios adicionales (setuid, setgid o setpcap), porque de lo contrario, podría inyectar una biblioteca diferente y ejecutar código arbitrario con privilegios elevados. (Consulte este artículo para obtener una explicación más detallada). El problema de seguridad se descubrió hace relativamente poco tiempo; en Debian se solucionó en DSA-2122-1 , por lo que antes de actualizar a libc6-2.7-18lenny6, su javaejecutable probablemente habría funcionado.

El síntoma indica que se javaestá ejecutando con privilegios adicionales. Este no es el caso en una instalación normal de Debian. Asegúrese de que /usr/lib/jvm/java-6-openjdk/jre/bin/javaesté en modo 755 y que no tenga ninguna capacidad ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javay setcap -r …de eliminar las capacidades si las hay).

(Respuesta original, que puede ser útil si encuentra que javafunciona como root pero no como otros usuarios, y resulta que está invocando diferentes binarios).

Mi apuesta es que tengas alguna otra javaversión anterior en tu PATH( sudocambia la PATH). Compruebe lo que type javadice: es probable que se trate de una versión de Java diferente para la que se ldd /path/to/bin/javainforma libjli.so => not found.

Y especulo que la razón por la que esta versión de Java no puede encontrar libjli.soes porque lo está buscando a través de un rpath (ruta de búsqueda de la biblioteca almacenada en el ejecutable) que no coincide con la forma en que está instalado. Si tiene el javabinario /some/where/bin/java, y tiene un rpath relativo (que es la forma de Sun JDK y OpenJDK), la biblioteca debería estar dentro /some/where/lib/i386/jli/libjli.so(suponiendo una arquitectura i386). Si la ruta es absoluta, debe colocar libjli.sola ubicación exacta especificada o establecerla LD_LIBRARY_PATHpara incluir dónde libjli.soestá.

Descargué "1.7.0_60" de java.com en .tar.gzformato y lo instalé /usr/local/jre1.7.0_60. Luego creé un enlace duro /usr/local/bin/javay recibí el error descrito anteriormente.

Cambiar el enlace rígido a un enlace simbólico solucionó el problema.

Version corta:

$ sudo ln /usr/local/jre1.7.0_60/bin/java /usr/local/bin/java

Es malo.

$ sudo ln -s /usr/local/jre1.7.0_60/bin/java /usr/local/bin/java

Es bueno.

Intenta encontrar el ejecutable de Java dentro de la misma ruta libjli.soy úsalo.

Por ejemplo, encontré libjli.soen /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, así que solía

find /usr/lib/jvm/java-7-oracle/ -name "java"

y encontré el ejecutable en /usr/lib/jvm/java-7-oracle/bin/java. Entonces, he eliminado javade /usr/biny justo por encima de un enlace simbólico al ejecutable /usr/bin.

Si el error se debe al uso de setcap en el ejecutable de Java, consulte

Cómo hacer que Oracle java 7 funcione con setcap cap_net_bind_service + ep y http://bugs.java.com/view_bug.do?bug_id=7157699

que responde a esta pregunta en detalle.

PD. En nuestro proyecto tuvimos que hacer

sudo setcap cap_net_bind_service=+ep /path/to/java

para permitir que java binary abra los puertos tcp / udp por debajo de 1024. Por encima de java "bug" 7157699 proporciona una solución rápida, al agregar un directorio donde libjli.so se encuentra en un archivo conf en la ruta /etc/ld.so.conf.d y luego llamando a ldconfig para volver a almacenar en caché las bibliotecas. Asumiendo Linux.

Verifique los permisos en ese archivo. Deberían verse así 0644/-rw-r--r--. Si no, reinstale openjdk-6-jre-headless, porque significaría que alguien se metió con los permisos.

Similar a la respuesta de Tshepang, forcé la libjli.soruta de búsqueda de la biblioteca:

# find / usr / lib / jvm -name \ libjli.so
/usr/lib/jvm/java-6-sun-1.6.0.45/jre/lib/amd64/jli/libjli.so

# export LD_LIBRARY_PATH = / usr / lib / jvm / java-6-sun / jre / lib / amd64 / jli: $ LD_LIBRARY_PATH

Como referencia, mi entorno de compilación usa github: flexiondotorg / oab-java6 en Ubuntu 10.04 / 64-bit.

Por alguna extraña razón /usr/bin/javaya no apuntaba a la instalación de Java. No tengo idea de cómo sucedió esto. Confirmé esto ejecutando:

$ sudo update-alternatives --config java

Lo que me dio lo siguiente

There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
Nothing to configure.
update-alternatives: warning: forcing reinstallation of alternative /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java because link group java is broken
update-alternatives: warning: not replacing /usr/bin/java with a link

Entonces, la solución fue eliminar Java /usr/local/biny crear un nuevo enlace simbólico:

$ sudo rm -rf /usr/bin/java
$ sudo ln -s /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java /usr/bin/java

Yo tenía el mismo error.

La forma más sencilla de resolverlo es simplemente eliminar todos los jdks y jres y también el ejecutable / usr / bin / java, si está allí.

Y luego reinstale jdk.

Resolvió el problema para mí. Mientras que otros métodos no lo hicieron.

Para cualquiera que intente iniciar una aplicación Java desde un servicio systemd y obtenga el mismo error, relacionado con la libjli.sobiblioteca, siga leyendo.

Actualmente hay un error abierto para esto para Fedora:

Error 1358476: SELinux evita que systemd ejecute servicios basados ​​en java

El resultado es que SELinux está restringiendo silenciosamente el acceso a esa biblioteca. Debido a que no hay un mensaje AVC denegado, no puede solucionarlo con contexto o cambio de política.

Descubrí que agregar un archivo /etc/ld.so.conf.d/que contiene la carpeta de su libjli.soarchivo es una solución alternativa:

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-5.b14.fc26.x86_64/jre/lib/amd64/jli/

Y luego corre

ldconfig

Pero eso es bastante desordenado ...

Una mejor opción es usar /bin/bash -cpara iniciar el proceso Java en su archivo de servicio:

ExecStart=/bin/bash -c "/usr/bin/java -Xmx1024m -jar myApp.jar NONINTERACTIVE"

Hasta que se solucione el problema ...