„Fehler beim Laden gemeinsam genutzter Bibliotheken:libjli.so:Datei mit gemeinsam genutzten Objekten kann nicht geöffnet werden:Keine solche Datei oder kein solches Verzeichnis“ Fehler „java -version“ beim Start

Das Problem

„java -version“ bricht mit der Fehlermeldung „Fehler beim Laden gemeinsam genutzter Bibliotheken:libjli.so:Datei mit gemeinsam genutzten Objekten kann nicht geöffnet werden:Keine solche Datei oder Verzeichnis“ ab, wenn versucht wird, die JVM zu starten.

Fall 1

Das Problem besteht, wenn es unter einem normalen Benutzer ausgeführt wird oder wenn es unter dem Root-Benutzer ausgeführt wird

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

Fall 2

Das Problem besteht nur, wenn es von einem normalen Benutzer ausgeführt wird. Es gibt kein Problem, wenn es unter dem Root-Benutzer ausgeführt wird.

Unter einem normalen Benutzer:

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

Unter root:

# [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)

Lösung für Fall 1

Entweder wurde nur die Java-Binärdatei in einen Ordner (z. B. /usr/bin/) kopiert, ohne den Rest der JRE- oder JDK-Verzeichnisse zu kopieren, oder es wurde nur ein Hardlink der Java-Binärdatei in dem Ordner erstellt (z. B. /usr/bin/). .

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

Wenn die Java-Launcher-Binärdatei die Dateien von JRE/JDK nicht finden kann, kann sie die JVM nicht starten. Die libjli.so ist dynamisch mit der Java-Binärdatei verknüpft. Es ist eine der ersten Bibliotheken, die der Java-Launcher zu laden versucht. Der Java Launcher muss alle zugehörigen Bibliotheken von Java lesen können, um ordnungsgemäß zu starten.

Es gibt zwei Möglichkeiten, dies zu lösen:

Lösung 1

Erstellen Sie anstelle eines Hardlinks oder einer Kopie einen symbolischen Link, wenn Sie Java aus dem Ordner /usr/bin aufrufen möchten.

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

Hinweis :Linux-Systeme, die den Befehl „update-alternatives“ unterstützen, sollten Lösung 2 unten verwenden, anstatt einen Symlink zu erstellen.

Lösung 2

Verwenden Sie den Befehl update-alternatives gemäß dem folgenden Beitrag, um den richtigen Java-Pfad festzulegen.

Der Befehl „java“ führt die installierte JVM nicht aus

Lösung für Fall 2

Hier gibt es 2 Szenarien:

Szenario 1

Die Datei „setcap “ wurde verwendet, um der Java-Binärdatei die richtige Berechtigung zu geben, um unprivilegierten Benutzern Sonderrechte zu gewähren. Zum Beispiel, um Ports kleiner als 1024 zu öffnen:

# setcap cap_net_bind_service=+ep /bin/java

Wenn die Berechtigungen einer ausführbaren Datei erhöht werden, wird der Runtime Loader (rtld), besser bekannt als ld.so, keine Verbindung zu Bibliotheken in nicht vertrauenswürdigen Pfaden herstellen. Auf diese Weise wurde ld.so(1) entworfen. Wenn eine solche ausführbare Datei ausgeführt werden muss, müssen die Pfade zu den zugehörigen Bibliotheken für die ausführbare Datei mit erhöhten Rechten zu den vertrauenswürdigen Pfaden von ld.so hinzugefügt werden.

Szenario 2

Das JDK/JRE wurde unter einem anderen Benutzerkonto (z. B. root) installiert und die weltweiten Leseberechtigungen wurden explizit entweder nur von libjli.so oder sogar von der gesamten JDK- oder JRE-Verzeichnisstruktur entfernt. Beispiel:

# chmod -R o-r [JAVA_HOME]

Wenn der Benutzer, der Java startet, keine Berechtigung zum Lesen der Bibliothek libjli.so hat, schlägt Java fehl. Dies liegt daran, dass libjli.so dynamisch mit der Java-Binärdatei verknüpft ist. Java muss in der Lage sein, alle seine dynamisch gelinkten Bibliotheken zu lesen, um richtig zu starten.

Lösung für Szenario 1

Hier gibt es 2 Lösungen:

1. Entfernen Sie die Fähigkeit wieder aus der Java-Binärdatei:

# setcap -r [JAVA_HOME]/bin/java

Stellen Sie sicher, dass die Java-Version jetzt funktioniert:

$ [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. Erstellen Sie eine Datei wie diese mit dem Pfad zu libjli.so:

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

Hinweis :Wenn Sie eine 32-Bit-JRE verwenden, ersetzen Sie amd64 durch i386.

Dadurch wird dieser Pfad zum vertrauenswürdigen Benutzerpfad hinzugefügt, den ld.so verwenden wird. Es kann erforderlich sein, den Laufzeitcache zu erstellen. Überprüfen Sie, ob ld.so es sieht, indem Sie wie folgt vorgehen. Die Befehle müssen als root ausgeführt werden. Möglicherweise ist ein Neustart erforderlich.

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

Stellen Sie sicher, dass die Java-Version jetzt funktioniert:

$ [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)

Lösung für Szenario 2

Stellen Sie die Leseberechtigungen wieder her, damit die libjli.so und andere Dateien aus den JDK/JRE-Verzeichnissen vom Benutzer gelesen werden können. Zum Beispiel:

# chmod -R o+r [JAVA_HOME]

Stellen Sie sicher, dass die Java-Version jetzt funktioniert:

$ [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)