Problema ao iniciar o java no Debian: “erro ao carregar bibliotecas compartilhadas: libjli.so”

Estou tentando iniciar o 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

Mas o java funciona como 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 é realmente meu comando 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:

Eu também tentei definir PATH raiz:

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

Eu tentei:

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

sob raiz. Mas não há variáveis ​​de ambiente utilizáveis ​​para java.

UPD4:

strace -f java -versionresultado: 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)

O executável que você está executando procura bibliotecas em um rpath , além do caminho normal de pesquisa da biblioteca. O rpath aqui é $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Normalmente, $ORIGINdeve ser substituído pela localização do executável aqui /usr/lib/jvm/java-6-openjdk/jre/bin.

Aqui, $ORIGINnão está sendo substituído. O recurso é desativado em executáveis ​​executando com privilégios extras (setuid, setgid ou setpcap), porque, caso contrário, você poderá injetar uma biblioteca diferente e, portanto, executar código arbitrário com privilégios elevados. (Consulte este artigo para obter uma explicação mais detalhada.) O problema de segurança foi descoberto relativamente recentemente; no Debian, ele foi corrigido no DSA-2122-1 ; portanto, antes de fazer o upgrade para libc6-2.7-18lenny6, seu javaexecutável provavelmente funcionaria.

O sintoma indica que javaestá sendo executado com privilégios adicionais. Este não é o caso em uma instalação Debian normal. Certifique-se de que /usr/lib/jvm/java-6-openjdk/jre/bin/javaé o modo de 755 e não tem qualquer capacidade ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javae setcap -r …para remover os recursos se houver).

(Resposta original, que pode ser útil se você achar que javafunciona como raiz, mas não como outros usuários, e se você invocar binários diferentes.)

Minha aposta é que você tem alguma outra java versão anterior no seu PATH( sudoaltera o PATH). Verifique o que type javadiz - provavelmente é uma versão Java diferente para quais ldd /path/to/bin/javarelatórios libjli.so => not found.

E especulo que o motivo que esta versão Java não consegue encontrar libjli.soé que ela está procurando por um rpath (caminho de pesquisa de biblioteca armazenado no executável) que não corresponde ao modo como está instalado. Se você possui o javabinário /some/where/bin/javae ele possui um rpath relativo (que é o caminho do Sun JDK e OpenJDK), a biblioteca deve estar /some/where/lib/i386/jli/libjli.so(assumindo uma arquitetura i386). Se o rpath for absoluto, você deverá colocarlibjli.so no local exato especificado ou definir LD_LIBRARY_PATHpara incluir onde libjli.soestá.

Eu baixei "1.7.0_60" de java.com em .tar.gz formato e instalei /usr/local/jre1.7.0_60. Em seguida, criei um link físico /usr/local/bin/javae recebi o erro descrito acima.

Alterar o link físico para um link simbólico corrigiu o problema.

Versão curta:

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

É ruim.

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

É bom.

Tente encontrar o executável java dentro do mesmo caminho libjli.soe usar isso.

Por exemplo, eu encontrei libjli.soem /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, então eu usei

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

e encontrou o executável em /usr/lib/jvm/java-7-oracle/bin/java. Então, eu apaguei javaa partir /usr/bine apenas simbolicamente acima em executável /usr/bin.

Se o erro ocorrer devido ao uso do setcap no executável Java, consulte

Como fazer com que o Oracle java 7 funcione com setcap cap_net_bind_service + ep e http://bugs.java.com/view_bug.do?bug_id=7157699

que responde a essa pergunta em detalhes.

ps. Em nosso projeto, tivemos que fazer

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

para permitir que o binário java abra portas tcp / udp abaixo de 1024. Acima, o java "bug" 7157699 fornece uma solução rápida, adicionando o diretório em que libjli.so está localizado em um arquivo conf no caminho /etc/ld.so.conf.d e, em seguida, chamando o ldconfig para armazenar novamente em cache as bibliotecas. Assumindo o Linux.

Verifique as permissões nesse arquivo. Eles devem se parecer 0644/-rw-r--r--. Caso contrário, reinstale openjdk-6-jre-headless, porque isso significaria que alguém mexeu com as permissões.

Semelhante à resposta de Tshepang, forcei libjli.soo caminho de pesquisa da biblioteca:

# find / usr / lib / nome-da-jvm \ 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

Para referência, meu ambiente de construção usa o github: flexiondotorg / oab-java6 no Ubuntu 10.04 / 64-bit.

Por algum motivo estranho, /usr/bin/javanão estava mais apontando para a instalação do java. Não faço ideia de como isso aconteceu. Confirmei isso executando:

$ sudo update-alternatives --config java

O que me deu o seguinte

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

Portanto, a solução foi remover o java /usr/local/bine criar um novo link simbólico:

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

Eu tive o mesmo erro.

A maneira mais simples de resolver isso é simplesmente remover todos os jdks e jres e também o executável / usr / bin / java, se houver.

E, em seguida, reinstale o jdk.

Isso resolveu o problema para mim. Enquanto outros métodos não.

Para quem tenta iniciar um aplicativo Java a partir de um serviço systemd e obtém o mesmo erro, relacionado ao libjli.so biblioteca, continue lendo.

Existe um bug em aberto para isso no Fedora atualmente:

Bug 1358476 - SELinux impedindo o systemd de executar serviços baseados em java

O resultado disso é que o SELinux está restringindo silenciosamente o acesso a essa biblioteca. Como não há mensagem negada pelo AVC, você não pode corrigi-la com contexto ou alteração de política.

Descobri que adicionar um arquivo /etc/ld.so.conf.d/que contém a pasta do seu libjli.soarquivo é uma solução alternativa:

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

E então corra

ldconfig

Mas isso é bem bagunçado ...

Uma opção melhor é usar /bin/bash -cpara iniciar o processo Java no seu arquivo de serviço:

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

Até que o problema seja resolvido ....