Problem beim Starten von Java unter Debian: "Fehler beim Laden der gemeinsam genutzten Bibliotheken: libjli.so"

Ich versuche Java zu starten:

$ 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

Aber Java funktioniert unter root:

$ 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 ist eigentlich mein Java-Befehl:

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

Ich habe auch versucht, root PATH zu setzen:

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

Ich bin müde:

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

unter root. Es gibt jedoch keine verwendbaren Umgebungsvariablen für Java.

UPD4:

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

Die ausführbare Datei, die Sie ausführen, sucht zusätzlich zum normalen Bibliothekssuchpfad in einem Pfad nach Bibliotheken. Der Weg hierher ist $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Normalerweise $ORIGINsollte hier der Ort der ausführbaren Datei ersetzt werden /usr/lib/jvm/java-6-openjdk/jre/bin.

Hier $ORIGINwird nicht ersetzt. Die Funktion ist in ausführbaren Dateien deaktiviert, die mit zusätzlichen Berechtigungen (setuid, setgid oder setpcap) ausgeführt werden, da Sie sonst möglicherweise eine andere Bibliothek einbinden und beliebigen Code mit erhöhten Berechtigungen ausführen können. (Weitere Informationen finden Sie in diesem Artikel .) Das Sicherheitsproblem wurde vor relativ kurzer Zeit entdeckt. in Debian wurde es in DSA-2122-1 behoben , so dass libc6-2.7-18lenny6Ihre javaausführbare Datei vermutlich funktioniert hätte , bevor Sie auf aktualisiert haben.

Das Symptom zeigt an, dass javamit zusätzlichen Berechtigungen ausgeführt wird. Dies ist in einer normalen Debian-Installation nicht der Fall. Stellen Sie sicher, dass /usr/lib/jvm/java-6-openjdk/jre/bin/javaes sich um den Modus 755 handelt und keine Funktionen aufweist ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javaund setcap -r …entfernen Sie die Funktionen, falls vorhanden).

(Ursprüngliche Antwort, die nützlich sein kann, wenn Sie feststellen, dass diese javaals root, aber nicht als anderer Benutzer funktioniert, und es sich herausstellt, dass Sie verschiedene Binärdateien aufrufen.)

Meine Wette ist, dass Sie eine andere javaVersion früher auf Ihrem haben PATH( sudoändert die PATH). Überprüfen Sie, was type javasagt - es ist wahrscheinlich eine andere Java-Version für welche ldd /path/to/bin/javaBerichte libjli.so => not found.

Und ich spekuliere, dass der Grund, warum diese Java-Version nicht gefunden werden kann, darin libjli.sobesteht, dass sie über einen Pfad (Bibliothekssuchpfad, der in der ausführbaren Datei gespeichert ist) sucht, der nicht der Art und Weise entspricht, in der sie installiert ist. Wenn Sie die javaBinärdatei /some/where/bin/javaeingegeben haben und sie einen relativen Pfad hat (dies ist der Weg von Sun JDK und OpenJDK), sollte sich die Bibliothek in befinden /some/where/lib/i386/jli/libjli.so(unter der Annahme einer i386-Architektur). Wenn der Pfad absolut ist, müssen Sie entweder libjli.soden genau angegebenen Speicherort eingeben oder festlegen LD_LIBRARY_PATH, wo libjli.sosich der Pfad befindet.

Ich habe "1.7.0_60" von java.com im .tar.gzFormat heruntergeladen und in installiert /usr/local/jre1.7.0_60. Ich habe dann einen festen Link zu erstellt /usr/local/bin/javaund den oben beschriebenen Fehler erhalten.

Durch Ändern des Hardlinks in einen symbolischen Link wurde das Problem behoben.

Kurzfassung:

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

Ist schlecht.

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

Ist gut.

Versuchen Sie, die ausführbare Java-Datei im selben Pfad wie zu finden, libjli.sound verwenden Sie diesen.

Zum Beispiel fand ich libjli.soin /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, so habe ich

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

und fand die ausführbare Datei in /usr/lib/jvm/java-7-oracle/bin/java. Dann gelöscht, ich javaaus /usr/binund gerade über ausführbare in Symlink /usr/bin.

Wenn der Fehler auf die Verwendung von setcap für die ausführbare Java-Datei zurückzuführen ist, lesen Sie

So funktioniert Oracle Java 7 mit setcap cap_net_bind_service + ep und http://bugs.java.com/view_bug.do?bug_id=7157699

was diese Frage im Detail beantwortet.

ps. In unserem Projekt mussten wir tun

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

Über Java "Bug" 7157699 bietet eine schnelle Lösung, indem das Verzeichnis, in dem sich libjli.so befindet, in eine conf-Datei in /etc/ld.so.conf.d Pfad und dann hinzugefügt wird Aufrufen von ldconfig zum erneuten Zwischenspeichern von Bibliotheken. Angenommen, Linux.

Überprüfen Sie die Berechtigungen für diese Datei. Sie sollten so aussehen 0644/-rw-r--r--. Wenn nicht, installieren Sie es erneut openjdk-6-jre-headless, da dies bedeuten würde, dass jemand mit den Berechtigungen in Unordnung geraten ist.

Ähnlich wie Tshepangs Antwort habe ich mich libjli.soin den Bibliothekssuchpfad gezwungen :

# 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-sonne / jre / lib / amd64 / jli: $ LD_LIBRARY_PATH

Als Referenz verwendet meine Build-Umgebung github: flexiondotorg / oab-java6 unter Ubuntu 10.04 / 64-bit.

Aus irgendeinem Grund /usr/bin/java wurde nicht mehr auf die Java-Installation hingewiesen. Keine Ahnung wie das passiert ist. Ich bestätigte dies durch Ausführen von:

$ sudo update-alternatives --config java

Welches gab mir die folgenden

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

Die Lösung bestand also darin, das Java-In zu entfernen /usr/local/binund einen neuen Symlink zu erstellen:

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

Ich hatte den gleichen fehler

Der einfachste Weg, dies zu lösen, besteht darin, einfach alle jdks und jres sowie die ausführbare Datei / usr / bin / java zu entfernen, falls vorhanden.

Und dann jdk neu installieren.

Es hat das Problem für mich gelöst. Während andere Methoden dies nicht taten.

Für alle, die versuchen, eine Java-Anwendung von einem systemd-Dienst aus zu starten und denselben Fehler im Zusammenhang mit dem zu erhalten libjli.soLesen Bibliothek erhalten möchten.

Es gibt derzeit einen offenen Fehler für Fedora:

Bug 1358476 - SELinux verhindert, dass systemd Java-basierte Dienste ausführt

Fazit ist, dass SELinux leise ist den Zugriff auf diese Bibliothek einschränkt. Da es keine AVC-Ablehnungsnachricht gibt, können Sie sie nicht mit dem Kontext oder einer Richtlinienänderung beheben.

Ich habe festgestellt, dass das Hinzufügen einer Datei /etc/ld.so.conf.d/, die den Ordner Ihrer libjli.soDatei enthält, eine Problemumgehung darstellt:

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

Und dann renn

ldconfig

Aber das ist ziemlich chaotisch ...

Eine bessere Möglichkeit besteht darin /bin/bash -c, den Java-Prozess in Ihrer Servicedatei zu starten:

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

Bis das Problem behoben ist ....