"Erreur lors du chargement des bibliothèques partagées :libjli.so :impossible d'ouvrir le fichier d'objet partagé :aucun fichier ou répertoire de ce type" Erreur "java -version" au démarrage

Le problème

"java -version" se ferme avec le message d'erreur "erreur lors du chargement des bibliothèques partagées :libjli.so :impossible d'ouvrir le fichier d'objet partagé :aucun fichier ou répertoire de ce type" lors de la tentative de démarrage de la JVM.

Cas 1

Le problème est là s'il est exécuté sous un utilisateur normal ou s'il est exécuté sous l'utilisateur root

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

Cas 2

Le problème n'est là que s'il est exécuté par un utilisateur normal. Il n'y a aucun problème s'il est exécuté sous l'utilisateur root.

Sous un utilisateur normal :

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

Sous racine :

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

Solution pour le cas 1

Soit seul le binaire Java a été copié en dur dans un dossier (par exemple /usr/bin/) sans copier le reste des répertoires JRE ou JDK, soit un lien physique du binaire Java a été créé dans le dossier (par exemple /usr/bin/) .

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

Si le binaire du lanceur Java ne trouve pas les fichiers du JRE/JDK, il ne parviendra pas à démarrer la JVM. Le libjli.so est lié dynamiquement au binaire Java. C'est l'une des premières bibliothèques que le lanceur Java essaie de charger. Le lanceur Java est nécessaire pour pouvoir lire toutes les bibliothèques associées à Java afin de démarrer correctement.

Il existe 2 façons de résoudre ce problème :

Solution 1

Créez un lien symbolique au lieu d'un lien physique ou d'une copie si vous souhaitez appeler Java depuis le dossier /usr/bin.

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

Remarque :Les systèmes Linux prenant en charge la commande "update-alternatives" doivent utiliser la solution 2 ci-dessous au lieu de créer un lien symbolique.

Solution 2

utilisez la commande update-alternatives conformément au message ci-dessous pour définir le chemin Java correct.

La commande "java" n'exécute pas la JVM qui a été installée

Solution pour le cas 2

Il y a 2 scénarios ici :

Scénario 1

Le "setcap ” a été utilisée pour donner au binaire Java la permission appropriée d'accorder des droits spéciaux aux utilisateurs non privilégiés. Par exemple, pour ouvrir des ports inférieurs à 1024 :

# setcap cap_net_bind_service=+ep /bin/java

Lors de l'augmentation des privilèges d'un exécutable, le chargeur d'exécution (rtld), mieux connu sous le nom de ld.so, ne sera pas lié aux bibliothèques dans des chemins non approuvés. C'est ainsi que ld.so(1) a été conçu. Si un tel exécutable doit être exécuté, les chemins d'accès aux bibliothèques associées pour l'exécutable élevé doivent être ajoutés aux chemins de confiance de ld.so.

Scénario 2

Le JDK/JRE a été installé sous un compte d'utilisateur différent (par exemple, root) et les autorisations de lecture mondiale ont été supprimées explicitement soit uniquement de libjli.so, soit même de l'ensemble de la structure de répertoires JDK ou JRE. Exemple :

# chmod -R o-r [JAVA_HOME]

Si l'utilisateur qui démarre Java n'a pas les autorisations pour lire la bibliothèque libjli.so, Java échouera. En effet, libjli.so est lié dynamiquement au binaire Java. Java doit être capable de lire toutes ses bibliothèques liées dynamiquement pour démarrer correctement.

Solution pour le scénario 1

Il y a 2 solutions ici :

1. Supprimez à nouveau la fonctionnalité du binaire Java :

# setcap -r [JAVA_HOME]/bin/java

Vérifiez que java -version fonctionne maintenant :

$ [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. Créez un fichier comme celui-ci, avec le chemin vers libjli.so :

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

Remarque :Si vous utilisez un JRE 32 bits, remplacez amd64 par i386.

Cela ajoutera ce chemin au chemin d'accès de l'utilisateur de confiance que ld.so utilisera. Il peut être nécessaire de créer le cache d'exécution. Vérifiez si ld.so le voit en procédant comme suit. Les commandes doivent être exécutées en tant que root. Un redémarrage peut être nécessaire.

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

Vérifiez que java -version fonctionne maintenant :

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

Solution pour le scénario 2

Restaurez les autorisations de lecture afin que libjli.so et les autres fichiers des répertoires JDK/JRE puissent être lus par l'utilisateur. Par exemple :

# chmod -R o+r [JAVA_HOME]

Vérifiez que java -version fonctionne maintenant :

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