Problem z uruchomieniem java w Debianie: „błąd podczas ładowania bibliotek współdzielonych: libjli.so”

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 -versionwynik: 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)

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 $ORIGINnależy zastąpić tutaj lokalizacją pliku wykonywalnego /usr/lib/jvm/java-6-openjdk/jre/bin.

Tutaj $ORIGINnie 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 do libc6-2.7-18lenny6, javaprawdopodobnie plik wykonywalny działałby.

Objaw wskazuje, że javadziała z dodatkowymi uprawnieniami. Nie jest tak w przypadku normalnej instalacji Debiana. Upewnij się, że /usr/lib/jvm/java-6-openjdk/jre/bin/javajest to tryb 755 i nie ma żadnych możliwości ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javaoraz, setcap -r …aby usunąć możliwości, jeśli istnieją).

(Oryginalna odpowiedź, która może być przydatna, jeśli okaże się, że javadział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ą javawersję PATH( sudozmienia PATH). Sprawdź, co type javamówi - to prawdopodobnie inna wersja Java dla której ldd /path/to/bin/javaraportów libjli.so => not found.

I spekuluję, że powodem, dla którego ta wersja Java nie może znaleźć, libjli.sojest 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 masz javaplik binarny /some/where/bin/javai 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.sowłączona (przy założeniu architektury i386). Jeśli ścieżka jest bezwzględna, musisz albo podać libjli.sodokładnie określoną lokalizację, albo ustawić, LD_LIBRARY_PATHaby uwzględnić gdzie libjli.sojest.

Pobrałem „1.7.0_60” ze strony java.com w .tar.gzformacie i zainstalowałem go /usr/local/jre1.7.0_60. Następnie utworzyłem twardy link do /usr/local/bin/javai otrzymałem błąd opisany powyżej.

Zmiana twardego linku na symboliczny naprawiła problem.

Krótka wersja:

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

Jest zły.

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

Jest dobry.

Spróbuj znaleźć plik wykonywalny Java w tej samej ścieżce libjli.soi użyj go.

Np. Znalazłem libjli.sow /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, więc użyłem

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

i znalazłem plik wykonywalny w /usr/lib/jvm/java-7-oracle/bin/java. Potem usunięte javaz /usr/bini właśnie dowiązane powyższe pod wykonywalnego /usr/bin.

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ć

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

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.

Sprawdź uprawnienia do tego pliku. Powinny wyglądać 0644/-rw-r--r--. Jeśli nie, zainstaluj ponownie openjdk-6-jre-headless, ponieważ oznaczałoby to, że ktoś miałby problemy z uprawnieniami.

Podobnie do odpowiedzi Tshepanga, wcisnąłem się w libjli.sościeżkę przeszukiwania biblioteki:

# find / usr / lib / jvm -name \ libjli.so
/usr/lib/jvm/java-6-sun-1.6.0.45/jre/lib/amd64/jli/libjli.so

# eksport LD_LIBRARY_PATH = / usr / lib / jvm / java-6-sun / jre / lib / amd64 / jli: $ LD_LIBRARY_PATH

Dla porównania, moje środowisko kompilacji używa github: flexiondotorg / oab-java6 na Ubuntu 10.04 / 64-bit.

Z jakiegoś dziwnego powodu /usr/bin/javanie wskazywał już na instalację Java. Nie mam pojęcia, jak to się stało. Potwierdziłem to, uruchamiając:

$ sudo update-alternatives --config java

Co dało mi następujące

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

Rozwiązaniem było więc usunięcie java /usr/local/bini utworzenie nowego dowiązania symbolicznego:

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

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.

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 folder libjli.sopliku to jedno obejście:

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

A potem biegnij

ldconfig

Ale to dość bałagan ...

Lepszą opcją jest /bin/bash -curuchomienie procesu Java w pliku usługi:

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

Do czasu rozwiązania problemu ....