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

Question

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 na raiz:

$ 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 é, na verdade, o 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 o 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)

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

UPD4:

strace -f java -version result: link

    

Answer 1

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 por bibliotecas em um rpath , além do caminho de pesquisa normal da biblioteca. O caminho aqui é $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli . Normalmente, $ORIGIN deve ser substituído pela localização do executável, aqui /usr/lib/jvm/java-6-openjdk/jre/bin .

Aqui, $ORIGIN não está sendo substituído. O recurso está desativado em executáveis executando com privilégios extras (setuid, setgid ou setpcap), porque senão você poderá injetar uma biblioteca diferente e, portanto, executar código arbitrário com privilégios elevados. (Veja este artigo para uma explicação mais detalhada.) A questão da segurança foi descoberta há relativamente pouco tempo; no Debian foi corrigido em DSA-2122-1 , então antes de você atualizar para libc6-2.7-18lenny6 , seu executável java presumivelmente teria funcionado.

O sintoma indica que java está 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 seja o modo 755 e não tenha recursos ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/java e setcap -r … para remover os recursos, se houver).

(Resposta original, que pode ser útil se você achar que java funciona como root, mas não como outros usuários, e acontece que você está invocando binários diferentes.)

Minha aposta é que você tenha outros java versão anterior em seu PATH ( sudo altera o PATH ). Verifique o que o type java diz - provavelmente é uma versão de Java diferente para a qual ldd /path/to/bin/java reporta libjli.so => not found .

E especulo que a razão pela qual essa versão do Java não pode encontrar libjli.so é que ela está procurando por um rpath (caminho de pesquisa de biblioteca armazenado no executável) que não corresponde à maneira como é instalado. Se você tiver o java binário em /some/where/bin/java e ele tiver um rpath relativo (que é o caminho do Sun JDK e OpenJDK), a biblioteca deve estar em /some/where/lib/i386/jli/libjli.so (assumindo uma arquitetura i386). Se o rpath for absoluto, será necessário colocar libjli.so no local especificado exato ou definir LD_LIBRARY_PATH para incluir onde libjli.so é.

    

Answer 2

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

A alteração do hardlink para um link simbólico resolveu o problema.

Versão resumida:

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

    

Answer 3

Tente encontrar o executável java dentro do mesmo caminho que libjli.so e use isso.

Por exemplo Eu encontrei libjli.so em /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so , então 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 deletei java de /usr/bin e apenas criei um link simbólico acima do executável em /usr/bin .

    

Answer 4

Se o bug for devido ao uso do setcap no executável Java, consulte

Como fazer com que o Oracle java 7 funcione com o setcap cap_net_bind_service + ep e link

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 as portas tcp / udp abaixo de 1024. Acima de java "bug", o 7157699 fornece uma solução rápida, adicionando o diretório onde libjli.so está localizado em um arquivo conf em /etc/ld.so.conf.d caminho e, em seguida, chamando ldconfig para re-armazenar em cache as bibliotecas. Assumindo o Linux.

    

Answer 5

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

    

Answer 6

Semelhante à resposta de Tshepang, forcei libjli.so para o caminho de pesquisa da biblioteca:

# 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

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

    

Answer 7

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

$ sudo update-alternatives --config java

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

A solução foi remover o java em /usr/local/bin e 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

    

Answer 8

Eu tive o mesmo erro.

A maneira mais simples de resolvê-lo é simplesmente remover todos os jdks e jres e também o executável / usr / bin / java, se estiver lá.

Em seguida, reinstale o jdk.

Resolveu o problema para mim. Enquanto outros métodos não o fizeram.

    

Answer 9

Para quem está tentando iniciar um aplicativo Java a partir de um serviço systemd e obtendo o mesmo erro, relacionado à biblioteca libjli.so , continue lendo.

Atualmente há um bug aberto para isso no Fedora:

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

Suposto que o SELinux está silenciosamente restringindo o acesso a essa biblioteca. Como não há mensagem de negação de AVC, não é possível corrigi-lo 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 arquivo libjli.so é 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, em seguida, execute

ldconfig

Mas isso é muito confuso ...

A melhor opção é usar /bin/bash -c para 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 corrigido ...