Próbuję uruchomić 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
Ale Java działa pod rootem:
$ 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 to właściwie moja komenda 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:
Próbowałem również ustawić ścieżkę root:
$ 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:
Jestem zmęczony:
# comm -3 <(declare | sort) <(declare -f | sort)
pod rootem. Ale nie ma przydatnych zmiennych środowiskowych dla java.
UPD4:
strace -f java -version
wynik: http://dumpz.org/67368/
debian
permissions
java
dynamic-linking
aetaur
źródło
źródło
strace -f java -version
i opublikuj wynik.Odpowiedzi:
Uruchamiany plik wykonywalny szuka bibliotek w ścieżce rpath oprócz zwykłej ścieżki wyszukiwania bibliotek. Ścieżka jest tutaj
$ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli
. Zwykle$ORIGIN
należy zastąpić tutaj lokalizacją pliku wykonywalnego/usr/lib/jvm/java-6-openjdk/jre/bin
.Tutaj
$ORIGIN
nie jest zastępowany. Ta funkcja jest wyłączona w plikach wykonywalnych z dodatkowymi uprawnieniami (setuid, setgid lub setpcap), ponieważ w przeciwnym razie możesz wstrzyknąć inną bibliotekę i uruchomić dowolny kod z podwyższonymi uprawnieniami. ( Bardziej szczegółowe wyjaśnienie znajduje się w tym artykule ). Problem bezpieczeństwa został odkryty stosunkowo niedawno; w Debianie zostało to naprawione w DSA-2122-1 , więc przed uaktualnieniem dolibc6-2.7-18lenny6
,java
prawdopodobnie plik wykonywalny działałby.Objaw wskazuje, że
java
działa z dodatkowymi uprawnieniami. Nie jest tak w przypadku normalnej instalacji Debiana. Upewnij się, że/usr/lib/jvm/java-6-openjdk/jre/bin/java
jest to tryb 755 i nie ma żadnych możliwości (getcap /usr/lib/jvm/java-6-openjdk/jre/bin/java
oraz,setcap -r …
aby usunąć możliwości, jeśli istnieją).(Oryginalna odpowiedź, która może być przydatna, jeśli okaże się, że
java
działa ona jako root, ale nie jako inni użytkownicy, i okazuje się, że wywołujesz różne pliki binarne).Założę się, że masz wcześniej inną
java
wersjęPATH
(sudo
zmieniaPATH
). Sprawdź, cotype java
mówi - to prawdopodobnie inna wersja Java dla którejldd /path/to/bin/java
raportówlibjli.so => not found
.I spekuluję, że powodem, dla którego ta wersja Java nie może znaleźć,
libjli.so
jest to, że szuka jej przez ścieżkę rpath (ścieżka wyszukiwania biblioteki przechowywana w pliku wykonywalnym), która nie pasuje do sposobu jej instalacji. Jeśli maszjava
plik binarny/some/where/bin/java
i ma on względną ścieżkę rpath (która jest sposobem działania Sun JDK i OpenJDK), biblioteka powinna być/some/where/lib/i386/jli/libjli.so
włączona (przy założeniu architektury i386). Jeśli ścieżka jest bezwzględna, musisz albo podaćlibjli.so
dokładnie określoną lokalizację, albo ustawić,LD_LIBRARY_PATH
aby uwzględnić gdzielibjli.so
jest.źródło
type java
export LD_LIBRARY_PATH=/usr/lib/jvm/java-6-openjdk/jre/lib/i386/jli/
, ale dostałem ten sam błąd.Pobrałem „1.7.0_60” ze strony java.com w
.tar.gz
formacie i zainstalowałem go/usr/local/jre1.7.0_60
. Następnie utworzyłem twardy link do/usr/local/bin/java
i otrzymałem błąd opisany powyżej.Zmiana twardego linku na symboliczny naprawiła problem.
Krótka wersja:
Jest zły.
Jest dobry.
źródło
Spróbuj znaleźć plik wykonywalny Java w tej samej ścieżce
libjli.so
i użyj go.Np. Znalazłem
libjli.so
w/usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so
, więc użyłemi znalazłem plik wykonywalny w
/usr/lib/jvm/java-7-oracle/bin/java
. Potem usuniętejava
z/usr/bin
i właśnie dowiązane powyższe pod wykonywalnego/usr/bin
.źródło
Jeśli błąd wynika z użycia setcap w pliku wykonywalnym Java, zapoznaj się z
Jak zmusić Oracle java 7 do pracy z setcap cap_net_bind_service + ep i http://bugs.java.com/view_bug.do?bug_id=7157699
który szczegółowo odpowiada na to pytanie.
ps. W naszym projekcie musieliśmy to zrobić
zezwalać programowi binarnemu Java na otwieranie portów tcp / udp poniżej 1024. Powyższy „błąd” 7157699 zapewnia szybkie rozwiązanie, dodając katalog, w którym znajduje się libjli.so, do pliku conf na ścieżce /etc/ld.so.conf.d, a następnie wywoływanie ldconfig w celu ponownego buforowania bibliotek. Zakładając Linux.
źródło
Sprawdź uprawnienia do tego pliku. Powinny wyglądać
0644/-rw-r--r--
. Jeśli nie, zainstaluj ponownieopenjdk-6-jre-headless
, ponieważ oznaczałoby to, że ktoś miałby problemy z uprawnieniami.źródło
ldd
zgłosi,libjli.so => not found
jeśli nie będzie mógł odczytać.so
(przynajmniej tak dzieje się z GLibc 2.11).Podobnie do odpowiedzi Tshepanga, wcisnąłem się w
libjli.so
ścieżkę przeszukiwania biblioteki:Dla porównania, moje środowisko kompilacji używa github: flexiondotorg / oab-java6 na Ubuntu 10.04 / 64-bit.
źródło
Z jakiegoś dziwnego powodu
/usr/bin/java
nie wskazywał już na instalację Java. Nie mam pojęcia, jak to się stało. Potwierdziłem to, uruchamiając:Co dało mi następujące
Rozwiązaniem było więc usunięcie java
/usr/local/bin
i utworzenie nowego dowiązania symbolicznego:źródło
Miałem ten sam błąd.
Najprostszym sposobem na rozwiązanie tego problemu jest po prostu usunięcie wszystkich plików JDK i Jres, a także pliku wykonywalnego / usr / bin / java, jeśli istnieje.
A następnie ponownie zainstaluj jdk.
To rozwiązało problem dla mnie. Podczas gdy inne metody nie.
źródło
Dla każdego, kto próbuje uruchomić aplikację Java z usługi systemowej i dostaje ten sam błąd, związany z
libjli.so
biblioteką, czytaj dalej.W tej chwili jest otwarty błąd dla Fedory:
Błąd 1358476 - SELinux uniemożliwiał systemdowi wykonywanie usług opartych na Javie
Wynikiem tego jest to, że SELinux po cichu ogranicza dostęp do tej biblioteki. Ponieważ nie ma komunikatu odmowy AVC, nie można go naprawić za pomocą kontekstu lub zmiany zasad.
Odkryłem, że dodanie pliku
/etc/ld.so.conf.d/
zawierającego folderlibjli.so
pliku to jedno obejście:A potem biegnij
Ale to dość bałagan ...
Lepszą opcją jest
/bin/bash -c
uruchomienie procesu Java w pliku usługi:Do czasu rozwiązania problemu ....
źródło
/bin/bash
? Co się stanie, jeśli użyjesz/bin/sh
?