Проблема для запуска Java в Debian: “ошибка, в то время как загрузка совместно использовала библиотеки: libjli.so”

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

Моя ставка - то, что у Вас есть некоторый другой 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 (который является способом JDK Sun и OpenJDK), библиотека должна быть в /some/where/lib/i386/jli/libjli.so (принятие i386 архитектуры). Если rpath является абсолютным, необходимо или поместить libjli.so в точном указанном месте или наборе LD_LIBRARY_PATH включать где libjli.so .

Проверьте полномочия на том файле. Они должны быть похожими 0644/-rw-r--r--. В противном случае переустановите openjdk-6-jre-headless, потому что это означало бы, что кто-то смешал с полномочиями.

Попытайтесь найти исполняемый файл 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 и просто symlinked выше исполняемого файла в /usr/bin.

Подобный ответу Tshepang, я вызвал 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.

Я скачал "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

Хорошо.

Для некоторой странной причины / 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

Я поставил более крупную статью на My Blog Но будет рекомендовать ниже того, как я решил этот вопрос, если мой сайт снизится.

Похоже, ACER-S7 поставляется с RAID0 из коробки после загрузки на USB-диске, вы увидите такие устройства, как / dev / md126 .

После установки обнаженной ОС вам необходимо убедиться, что вы загружаетесь с initramfs, которые могут распознать этот RAID.

Для меня решение было для DD следующих линий в /etc/mkinitcpio.conf :

MODULES="ext4 dm_mod raid0"
...
HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck shutdown"

Затем установите initramfs и обновляйте GRUB со следующими командами:

mkinitcpio -p linux
grub-mkconfig > /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub_uefi --boot-directory=/boot --recheck 

Если ошибка связана с использованием SetCap на исполняемости Java, а затем обратитесь к

Как получить Oracle Java 7 работать с SetCap Cap_net_Bind_Service + EP и http://bugs.java.com/view_bug.do?bug_id=7157699

, который отвечает на этот вопрос в деталях.

PS. В нашем проекте нам пришлось сделать

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

, чтобы позволить Java Binary для открытия портов TCP / UDP ниже 1024. Над java "Bug" 7157699 обеспечивает быстрое решение, добавляя каталог, в котором Libjli.so находится в файл CONT в / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc / etc ld.so.conf.d Путь и затем вызова ldconfig для переоборудования библиотек. Предполагая Linux.

У меня была такая же ошибка.

Самый простой способ решить эту проблему - просто удалить все 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"

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