Проблема при запуске 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 работает под 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 на самом деле моя команда 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:

Я также попытался установить корневой путь:

$ 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 в дополнение к обычному пути поиска библиотек. 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и только что выполнил ссылку выше исполняемого файла в /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 открывать порты 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путь поиска в библиотеке:

# 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

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

По какой-то странной причине /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 не позволяет systemd выполнять службы на основе 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"

Пока проблема не устранена ....