Problème pour lancer java sur Debian: "erreur lors du chargement des bibliothèques partagées: libjli.so"

J'essaie de lancer 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

Mais java fonctionne sous 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 est en fait ma commande 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:

J'ai également essayé de définir le PATH racine:

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

Je suis fatigué:

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

sous racine. Mais il n'y a pas de variables d'environnement utilisables pour java.

UPD4:

strace -f java -versionrésultat: 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'exécutable que vous exécutez recherche des bibliothèques dans un chemin d' accès en plus du chemin de recherche de bibliothèque normal. Le chemin est ici $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Normalement, $ORIGINdevrait être remplacé par l'emplacement de l'exécutable, ici /usr/lib/jvm/java-6-openjdk/jre/bin.

Ici, $ORIGINn'est pas remplacé. La fonctionnalité est désactivée dans les exécutables exécutés avec des privilèges supplémentaires (setuid, setgid ou setpcap), car sinon vous pourriez être en mesure d'injecter une bibliothèque différente et d'exécuter ainsi du code arbitraire avec des privilèges élevés. (Voir cet article pour une explication plus détaillée.) Le problème de sécurité a été découvert relativement récemment; dans Debian, il a été corrigé dans DSA-2122-1 , donc avant de passer à libc6-2.7-18lenny6, votre javaexécutable aurait probablement fonctionné.

Le symptôme indique qu'il javas'exécute avec des privilèges supplémentaires. Ce n'est pas le cas dans une installation Debian normale. Assurez-vous qu'il /usr/lib/jvm/java-6-openjdk/jre/bin/javas'agit du mode 755 et qu'il n'a aucune capacité ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/java, et setcap -r …pour supprimer les capacités le cas échéant).

(Réponse originale, qui peut être utile si vous trouvez que cela javafonctionne en tant que root mais pas en tant que d'autres utilisateurs, et il s'avère que vous invoquez différents binaires.)

Je parie que vous avez une autre javaversion plus tôt sur votre PATH( sudochange la PATH). Vérifiez ce qui est type javadit - c'est probablement une version Java différente pour laquelle les ldd /path/to/bin/javarapports libjli.so => not found.

Et je spécule que la raison pour laquelle cette version Java ne peut pas trouver libjli.soest qu'elle la recherche via un rpath (chemin de recherche de bibliothèque stocké dans l'exécutable) qui ne correspond pas à la façon dont il est installé. Si vous avez le javabinaire dans /some/where/bin/javaet qu'il a un chemin d'accès relatif (qui est le chemin du Sun JDK et OpenJDK), la bibliothèque devrait être dans /some/where/lib/i386/jli/libjli.so(en supposant une architecture i386). Si le chemin d'accès est absolu, vous devez soit placer libjli.soà l'emplacement spécifié exact, soit définir LD_LIBRARY_PATHpour inclure où libjli.soest.

J'ai téléchargé "1.7.0_60" de java.com au .tar.gzformat et l' ai installé dans /usr/local/jre1.7.0_60. J'ai ensuite créé un lien dur vers /usr/local/bin/javaet reçu l'erreur décrite ci-dessus.

Changer le lien dur en un lien symbolique a résolu le problème.

Version courte:

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

Est mauvais.

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

Est bon.

Essayez de trouver l'exécutable java dans le même chemin que libjli.soet utilisez-le.

Par exemple, j'ai trouvé libjli.sodans /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, donc j'ai utilisé

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

et a trouvé l'exécutable dans /usr/lib/jvm/java-7-oracle/bin/java. Ensuite, je supprimé à javapartir /usr/binet juste au- dessus des liens symboliques exécutable dans /usr/bin.

Si le bogue est dû à l'utilisation de setcap sur un exécutable Java, reportez-vous à

Comment faire fonctionner Oracle java 7 avec setcap cap_net_bind_service + ep et http://bugs.java.com/view_bug.do?bug_id=7157699

qui répond à cette question en détail.

ps. Dans notre projet, nous devions faire

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

pour autoriser le binaire java à ouvrir les ports tcp / udp en dessous de 1024. Le "bogue" java 7157699 fournit une solution rapide, en ajoutant le répertoire où libjli.so se trouve dans un fichier conf dans le chemin /etc/ld.so.conf.d, puis appeler ldconfig pour remettre en cache les bibliothèques. En supposant que Linux.

Vérifiez les autorisations sur ce fichier. Ils devraient ressembler 0644/-rw-r--r--. Sinon, réinstallez openjdk-6-jre-headless, car cela signifierait que quelqu'un a foiré les autorisations.

Semblable à la réponse de Tshepang, j'ai forcé libjli.sodans le chemin de recherche de la bibliothèque:

# 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

Pour référence, mon environnement de build utilise github: flexiondotorg / oab-java6 sur Ubuntu 10.04 / 64-bit.

Pour une raison étrange, je /usr/bin/javane pointais plus vers l'installation java. Je ne sais pas comment cela s'est produit. J'ai confirmé cela en exécutant:

$ sudo update-alternatives --config java

Ce qui m'a donné ce qui suit

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

La solution a donc été de supprimer le java /usr/local/binet de créer un nouveau lien symbolique:

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

J'ai eu la même erreur.

Le moyen le plus simple de le résoudre est de supprimer simplement tous les jdks et jres ainsi que l'exécutable / usr / bin / java, s'il existe.

Et puis réinstallez jdk.

Cela a résolu le problème pour moi. Alors que d'autres méthodes ne l'ont pas fait.

Pour toute personne essayant de démarrer une application Java à partir d'un service systemd et obtenant la même erreur, liée à la libjli.sobibliothèque, lisez la suite.

Il existe actuellement un bogue ouvert pour Fedora:

Bogue 1358476 - SELinux empêchant systemd d'exécuter des services basés sur java

En résumé, SELinux restreint silencieusement l'accès à cette bibliothèque. Parce qu'il n'y a pas de message refusé par AVC, vous ne pouvez pas le corriger avec le contexte ou un changement de stratégie.

J'ai constaté que l'ajout d'un fichier /etc/ld.so.conf.d/contenant le dossier de votre libjli.sofichier est une solution de contournement:

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

Et puis exécutez

ldconfig

Mais c'est assez compliqué ...

Une meilleure option consiste à utiliser /bin/bash -cpour lancer le processus Java dans votre fichier de service:

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

Jusqu'à ce que le problème soit résolu ...