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 -version
resultado: http://dumpz.org/67368/
debian
permissions
java
dynamic-linking
aetaur
fuente
fuente
strace -f java -version
y publique la salida.Respuestas:
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$ORIGIN
debería ser reemplazado por la ubicación del ejecutable, aquí/usr/lib/jvm/java-6-openjdk/jre/bin
.Aquí,
$ORIGIN
no 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 alibc6-2.7-18lenny6
, sujava
ejecutable probablemente habría funcionado.El síntoma indica que se
java
está 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/java
esté en modo 755 y que no tenga ninguna capacidad (getcap /usr/lib/jvm/java-6-openjdk/jre/bin/java
ysetcap -r …
de eliminar las capacidades si las hay).(Respuesta original, que puede ser útil si encuentra que
java
funciona como root pero no como otros usuarios, y resulta que está invocando diferentes binarios).Mi apuesta es que tengas alguna otra
java
versión anterior en tuPATH
(sudo
cambia laPATH
). Compruebe lo quetype java
dice: es probable que se trate de una versión de Java diferente para la que seldd /path/to/bin/java
informalibjli.so => not found
.Y especulo que la razón por la que esta versión de Java no puede encontrar
libjli.so
es 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 eljava
binario/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 colocarlibjli.so
la ubicación exacta especificada o establecerlaLD_LIBRARY_PATH
para incluir dóndelibjli.so
está.fuente
type java
export LD_LIBRARY_PATH=/usr/lib/jvm/java-6-openjdk/jre/lib/i386/jli/
obtuve el mismo error.Descargué "1.7.0_60" de java.com en
.tar.gz
formato y lo instalé/usr/local/jre1.7.0_60
. Luego creé un enlace duro/usr/local/bin/java
y recibí el error descrito anteriormente.Cambiar el enlace rígido a un enlace simbólico solucionó el problema.
Version corta:
Es malo.
Es bueno.
fuente
Intenta encontrar el ejecutable de Java dentro de la misma ruta
libjli.so
y úsalo.Por ejemplo, encontré
libjli.so
en/usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so
, así que solíay encontré el ejecutable en
/usr/lib/jvm/java-7-oracle/bin/java
. Entonces, he eliminadojava
de/usr/bin
y justo por encima de un enlace simbólico al ejecutable/usr/bin
.fuente
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
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.
fuente
Verifique los permisos en ese archivo. Deberían verse así
0644/-rw-r--r--
. Si no, reinstaleopenjdk-6-jre-headless
, porque significaría que alguien se metió con los permisos.fuente
ldd
informaríalibjli.so => not found
si no pudiera leer el.so
(al menos eso es lo que sucede con GLibc 2.11).Similar a la respuesta de Tshepang, forcé la
libjli.so
ruta de búsqueda de la biblioteca:Como referencia, mi entorno de compilación usa github: flexiondotorg / oab-java6 en Ubuntu 10.04 / 64-bit.
fuente
Por alguna extraña razón
/usr/bin/java
ya no apuntaba a la instalación de Java. No tengo idea de cómo sucedió esto. Confirmé esto ejecutando:Lo que me dio lo siguiente
Entonces, la solución fue eliminar Java
/usr/local/bin
y crear un nuevo enlace simbólico:fuente
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.
fuente
Para cualquiera que intente iniciar una aplicación Java desde un servicio systemd y obtenga el mismo error, relacionado con la
libjli.so
biblioteca, 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 sulibjli.so
archivo es una solución alternativa:Y luego corre
Pero eso es bastante desordenado ...
Una mejor opción es usar
/bin/bash -c
para iniciar el proceso Java en su archivo de servicio:Hasta que se solucione el problema ...
fuente
/bin/bash
? ¿Qué pasa si lo usas/bin/sh
?