Problema di avviare java su Debian: "errore durante il caricamento delle librerie condivise: libjli.so"

Sto provando a lanciare 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

Ma java funziona alla radice:

$ 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 è in realtà il mio 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:

Ho anche provato a impostare il PERCORSO root:

$ 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:

Sono provato:

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

sotto radice. Ma non ci sono variabili d'ambiente utilizzabili per Java.

UPD4:

strace -f java -versionrisultato: 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)

L'eseguibile che stai eseguendo cerca le librerie in un rpath oltre al normale percorso di ricerca delle librerie. Il percorso qui è $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Normalmente $ORIGINdovrebbe essere sostituito dalla posizione dell'eseguibile, qui /usr/lib/jvm/java-6-openjdk/jre/bin.

Qui, $ORIGINnon viene sostituito. La funzione è disattivata negli eseguibili in esecuzione con privilegi extra (setuid, setgid o setpcap), perché altrimenti potresti essere in grado di iniettare una libreria diversa e quindi eseguire codice arbitrario con privilegi elevati. (Vedi questo articolo per una spiegazione più dettagliata.) Il problema di sicurezza è stato scoperto relativamente di recente; in Debian è stato corretto in DSA-2122-1 , quindi prima di passare a libc6-2.7-18lenny6, il tuo javaeseguibile avrebbe presumibilmente funzionato.

Il sintomo indica che javaè in esecuzione con privilegi aggiuntivi. Questo non è il caso di una normale installazione Debian. Assicurarsi che /usr/lib/jvm/java-6-openjdk/jre/bin/javasia la modalità 755 e non abbia alcuna capacità ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javae setcap -r …per rimuovere le capacità se presenti).

(Risposta originale, che può essere utile se trovi che javafunziona come root ma non come altri utenti, e si scopre che stai invocando binari diversi.)

La mia scommessa è che hai un'altra javaversione precedente sul tuo PATH( sudocambia il PATH). Controlla cosa type javadice: probabilmente è una versione Java diversa per la quale ldd /path/to/bin/javariporta libjli.so => not found.

E suppongo che il motivo che questa versione di Java non riesce a trovare libjli.soè che la sta cercando attraverso un rpath (percorso di ricerca della libreria memorizzato nell'eseguibile) che non corrisponde al modo in cui è installato. Se si dispone del javabinario /some/where/bin/javae ha un percorso relativo (che è il modo di Sun JDK e OpenJDK), la libreria dovrebbe trovarsi /some/where/lib/i386/jli/libjli.so(assumendo un'architettura i386). Se il percorso è assoluto, è necessario inserire libjli.sol'esatta posizione specificata o impostare LD_LIBRARY_PATHper includere dove si libjli.sotrova.

Ho scaricato "1.7.0_60" da java.com in .tar.gz formato e l'ho installato in /usr/local/jre1.7.0_60. Ho quindi creato un collegamento reale /usr/local/bin/javae ho ricevuto l'errore sopra descritto.

La modifica del collegamento fisico in un collegamento simbolico ha risolto il problema.

Versione breve:

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

È cattivo.

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

È buono.

Prova a trovare l'eseguibile Java all'interno dello stesso percorso libjli.soe usalo.

Ad esempio, ho trovato libjli.soin /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, quindi ho usato

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

e ho trovato il file eseguibile in /usr/lib/jvm/java-7-oracle/bin/java. Quindi, ho eliminato javada /usr/bine appena linkato sopra eseguibile in /usr/bin.

Se il bug è dovuto all'uso di setcap sull'eseguibile Java, fare riferimento a

Come far funzionare Oracle Java 7 con setcap cap_net_bind_service + ep e http://bugs.java.com/view_bug.do?bug_id=7157699

che risponde a questa domanda in dettaglio.

ps. Nel nostro progetto abbiamo dovuto fare

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

per consentire a java binary di aprire le porte tcp / udp al di sotto di 1024. Sopra java "bug" 7157699 fornisce una soluzione rapida, aggiungendo la directory in cui libjli.so si trova in un file conf nel percorso /etc/ld.so.conf.d e quindi chiamando ldconfig per ri-cache delle librerie. Supponendo Linux.

Controlla le autorizzazioni su quel file. Dovrebbero apparire come 0644/-rw-r--r--. In caso contrario, reinstallare openjdk-6-jre-headless, perché significherebbe che qualcuno ha incasinato le autorizzazioni.

Simile alla risposta di Tshepang, ho forzato libjli.so il percorso di ricerca della 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

Per riferimento, il mio ambiente di compilazione usa github: flexiondotorg / oab-java6 su Ubuntu 10.04 / 64-bit.

Per qualche strana ragione /usr/bin/javanon puntava più all'installazione di Java. Non ho idea di come sia successo. Ho confermato eseguendo:

$ sudo update-alternatives --config java

Il che mi ha dato quanto segue

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

Quindi la soluzione era rimuovere java /usr/local/bine creare un nuovo link simbolico:

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

Ho avuto lo stesso errore.

Il modo più semplice per risolverlo è semplicemente rimuovere tutti i jdks e jres e anche l'eseguibile / usr / bin / java, se è lì.

E quindi reinstallare jdk.

Mi ha risolto il problema. Mentre altri metodi no.

Per chiunque cerchi di avviare un'applicazione Java da un servizio systemd e ottenga lo stesso errore, relativo alla libjli.solibreria, continua a leggere.

Al momento esiste un bug aperto per Fedora:

Bug 1358476 - SELinux impedisce a systemd di eseguire servizi basati su Java

Il risultato è che SELinux è silenzioso limitando l'accesso a quella libreria. Poiché non è stato negato il messaggio AVC, non è possibile correggerlo con il contesto o la modifica dei criteri.

Ho scoperto che l'aggiunta di un file /etc/ld.so.conf.d/che contiene la cartella del tuo libjli.sofile è una soluzione alternativa:

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

E poi corri

ldconfig

Ma è piuttosto disordinato ...

Un'opzione migliore è utilizzare /bin/bash -cper avviare il processo Java nel file di servizio:

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

Fino a quando il problema non viene risolto ....