"errore durante il caricamento delle librerie condivise:libjli.so:impossibile aprire il file oggetto condiviso:nessun file o directory del genere" Errore 'java -version' all'avvio

Il problema

"java -version" si chiude con il messaggio di errore "errore durante il caricamento delle librerie condivise:libjli.so:impossibile aprire il file oggetto condiviso:nessun file o directory del genere" quando si tenta di avviare la JVM.

Caso 1

Il problema esiste se viene eseguito con un utente normale o se viene eseguito con l'utente root

$ java -version
[PATH_TO]/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Caso 2

Il problema c'è solo se è eseguito da un utente normale. Non ci sono problemi se viene eseguito con l'utente root.

Sotto un utente normale:

$ java -version
[JAVA_HOME]/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Sotto root:

# [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

Soluzione per il caso 1

O solo il binario Java è stato copiato su carta in una cartella (ad es. /usr/bin/) senza copiare il resto delle directory JRE o JDK oppure è stato creato solo un hardlink del binario Java nella cartella (ad es. /usr/bin/) .

# cp [JAVA_HOME]/jre/bin/java /usr/bin/

Se il binario di avvio di Java non riesce a trovare i file di JRE/JDK, non riuscirà ad avviare la JVM. libjli.so è collegato dinamicamente al binario Java. È una delle prime librerie che Java Launcher tenta di caricare. Il programma di avvio Java è necessario per poter leggere tutte le librerie associate a Java per avviarsi correttamente.

Ci sono 2 modi per risolvere questo problema:

Soluzione 1

Crea un link simbolico invece di un hardlink o una copia se vuoi chiamare Java dalla cartella /usr/bin.

# sudo ln -s [path to the JRE's java binary] /usr/bin/java

Nota :I sistemi Linux che supportano il comando "update-alternatives" dovrebbero utilizzare la soluzione 2 di seguito invece di creare un collegamento simbolico.

Soluzione 2

usa il comando update-alternatives come indicato nel post qui sotto per impostare il percorso java corretto.

Il comando "java" non esegue la JVM che è stata installata

Soluzione per il caso 2

Ci sono 2 scenari qui:

Scenario 1

Il "limite massimo Il comando ” è stato utilizzato per dare al binario Java l'autorizzazione appropriata per concedere diritti speciali agli utenti senza privilegi. Ad esempio, per aprire porte inferiori a 1024:

# setcap cap_net_bind_service=+ep /bin/java

Quando si aumentano i privilegi di un eseguibile, il caricatore di runtime (rtld), meglio noto come ld.so, non si collegherà alle librerie in percorsi non attendibili. Questo è il modo in cui è stato progettato ld.so(1). Se è necessario eseguire un tale eseguibile, i percorsi delle librerie associate per l'eseguibile con privilegi elevati devono essere aggiunti ai percorsi attendibili di ld.so.

Scenario 2

JDK/JRE è stato installato con un account utente diverso (ad es. root) e le autorizzazioni di lettura globale sono state rimosse esplicitamente solo da libjli.so o anche dall'intera struttura di directory JDK o JRE. Esempio:

# chmod -R o-r [JAVA_HOME]

Se l'utente che avvia Java non ha i permessi per leggere la libreria libjli.so, Java fallirà. Questo perché libjli.so è collegato dinamicamente al binario Java. Java deve essere in grado di leggere tutte le sue librerie collegate dinamicamente per poter iniziare correttamente.

Soluzione per lo scenario 1

Ci sono 2 soluzioni qui:

1. Rimuovere nuovamente la funzionalità dal binario Java:

# setcap -r [JAVA_HOME]/bin/java

Verifica che java -version funzioni ora:

$ [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

2. Crea un file come questo, con il percorso a libjli.so:

$ cat /etc/ld.so.conf.d/java.conf
[JAVA_HOME]/jre/lib/amd64/jli

Nota :Se utilizzi un JRE a 32 bit, sostituisci amd64 con i386.

Questo aggiungerà quel percorso al percorso dell'utente affidabile che utilizzerà ld.so. Potrebbe essere necessario creare la cache di runtime. Verifica se ld.so lo sta vedendo procedendo come segue. I comandi devono essere eseguiti come root. Potrebbe essere necessario un riavvio.

# ldconfig | grep libjli
libjli.so -> libjli.so
.......

Verifica che java -version funzioni ora:

$ [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

Soluzione per lo scenario 2

Ripristinare le autorizzazioni di lettura in modo che libjli.so e altri file dalle directory JDK/JRE possano essere letti dall'utente. Ad esempio:

# chmod -R o+r [JAVA_HOME]

Verifica che java -version funzioni ora:

$ [JAVA_HOME]/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)