Проблема запустити Java на Debian: "помилка під час завантаження спільних бібліотек: libjli.so"

Я намагаюся запустити 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

Але java працює під коренем:

$ 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 - це фактично моя команда 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:

Я також намагався встановити root PATH:

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

Мене намагаються:

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

під корінь. Але змінних середовища для Java немає.

UPD4:

strace -f java -versionрезультат: 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)

Виконаний файл, який ви працюєте, шукає бібліотеки на rpath на додаток до звичайного шляху пошуку бібліотеки. Тут є шлях $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Зазвичай тут $ORIGINслід замінити розташування виконуваного файлу /usr/lib/jvm/java-6-openjdk/jre/bin.

Тут $ORIGINне замінюється. Ця функція вимкнена у виконуваних файлах із додатковими привілеями (setuid, setgid чи setpcap), тому що в іншому випадку ви можете ввести іншу бібліотеку та запустити довільний код з підвищеними привілеями. ( Більш детальне пояснення див. У цій статті .) Проблему безпеки було виявлено відносно недавно; в Debian це було зафіксовано в DSA-2122-1 , тому перед оновленням libc6-2.7-18lenny6ваш javaвиконавчий файл, імовірно, працював.

Симптом вказує на те, що javaпрацює з додатковими привілеями. Це не так у звичайній установці Debian. Переконайтеся, що /usr/lib/jvm/java-6-openjdk/jre/bin/javaце режим 755 і не має жодних можливостей ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javaі setcap -r …видалити можливості, якщо такі є).

(Оригінальна відповідь, яка може бути корисною, якщо ви виявите, що вона javaпрацює як root, але не як інші користувачі, і виявляється, що ви викликаєте різні бінарні файли.)

Моя обставина, що у вас є інша javaверсія раніше на вашій PATH( sudoзмінює PATH). Перевірте, що type javaговорить - це, мабуть, якась інша версія Java, для якої ldd /path/to/bin/javaзвіти libjli.so => not found.

І я припускаю, що причина, яку ця версія Java не може знайти, libjli.soполягає в тому, що вона шукає її через rpath (шлях пошуку бібліотеки, що зберігається у виконуваному файлі), який не відповідає тому, як він встановлений. Якщо у вас є javaбінарний /some/where/bin/javaкод, і він має відносний rpath (що є способом Sun JDK та OpenJDK), бібліотека повинна знаходитись /some/where/lib/i386/jli/libjli.so(припускаючи архітектуру i386). Якщо rpath абсолютний, потрібно або поставити libjli.soв точно вказане місце, або встановити, LD_LIBRARY_PATHщоб вказати, де libjli.soє.

Я завантажив "1.7.0_60" з java.com у .tar.gzформаті та встановив його /usr/local/jre1.7.0_60. Потім я створив жорстке посилання на /usr/local/bin/javaі отримав описану вище помилку.

Зміна жорсткого посилання на символічне посилання вирішила проблему.

Коротка версія:

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

Погано.

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

Це добре.

Спробуйте знайти виконуваний файл Java в тому ж шляху, що libjli.soі використовувати його.

Наприклад , я знайшов libjli.soв /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, так що я використовував

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

і знайшов виконуваний файл у /usr/lib/jvm/java-7-oracle/bin/java. Потім я видалив javaз /usr/binі тільки символьних посилань вище виконуваного INTO /usr/bin.

Якщо помилка пов’язана з використанням setcap на виконаному Java, тоді зверніться до сторінки

Як змусити Oracle java 7 працювати з setcap cap_net_bind_service + ep та http://bugs.java.com/view_bug.do?bug_id=7157699

який детально відповідає на це питання.

пс. У нашому проекті нам довелося це зробити

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

щоб дозволити java binary відкривати порти tcp / udp нижче 1024. Вище java "помилка" 7157699 забезпечує швидке рішення, додавши каталог, де libjli.so розташований у файл conf в /etc/ld.so.conf.d шлях, а потім виклик ldconfig для повторного кешування бібліотек. Припустимо, що Linux.

Перевірте дозволи на цей файл. Вони повинні мати вигляд 0644/-rw-r--r--. Якщо ні, перевстановіть openjdk-6-jre-headless, бо це означатиме, що хтось заплутався з дозволами.

Подібно до відповіді Чепанга, я змусив мене libjli.soшукати шлях бібліотеки:

# знайти / usr / lib / jvm -name \ libjli.so
/usr/lib/jvm/java-6-sun-1.6.0.45/jre/lib/amd64/jli/libjli.so

# експорт LD_LIBRARY_PATH = / usr / lib / jvm / java-6-sun / jre / lib / amd64 / jli: $ LD_LIBRARY_PATH

Для довідки, моє середовище побудови використовує github: flexiondotorg / oab-java6 на Ubuntu 10.04 / 64-біт.

Чомусь /usr/bin/javaбільше не вказували на установку java. Не знаю, як це сталося. Я підтвердив це, запустивши:

$ sudo update-alternatives --config java

Що дало мені таке

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

Таким чином, рішенням було видалити java у /usr/local/binі створити нове символьне посилання:

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

У мене була така ж помилка.

Найпростіший спосіб її вирішити - просто видалити всі jdks та jres, а також виконуваний файл / usr / bin / java, якщо він є.

А потім перевстановіть jdk.

Це вирішило проблему для мене. Хоча інших методів не було.

Для тих, хто намагається запустити програму Java із сервісу systemd та отримати ту саму помилку, що стосується libjli.soбібліотеки, читайте далі.

Зараз для Fedora відкрита помилка для цього:

Помилка 1358476 - SELinux, що запобігає системному виконанню служб на базі Java

Підсумок цього полягає в тому, що SELinux мовчки обмежує доступ до цієї бібліотеки. Оскільки повідомлення з відхиленням AVC відсутнє, ви не можете його виправити за допомогою контексту чи зміни політики.

Я виявив, що додавання файлу, /etc/ld.so.conf.d/який містить папку вашого libjli.soфайлу, є одним вирішенням:

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

А потім біжи

ldconfig

Але це досить безладно ...

Кращим варіантом є використання /bin/bash -cдля запуску процесу Java у вашому сервісному файлі:

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

Поки питання не буде вирішено….