問題
JVM を起動しようとすると、「java -version」が「共有ライブラリの読み込み中にエラーが発生しました:libjli.so:共有オブジェクト ファイルを開けません:そのようなファイルまたはディレクトリはありません」というエラー メッセージが表示されて終了します。
ケース 1
通常のユーザーで実行した場合、または root ユーザーで実行した場合に問題があります
$ java -version [PATH_TO]/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
ケース 2
問題は、通常のユーザーが実行した場合にのみ発生します。 root ユーザーで実行しても問題ありません。
一般ユーザーの場合:
$ java -version [JAVA_HOME]/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
ルートの下:
# [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)
ケース 1 の解決策
残りの JRE または JDK ディレクトリをコピーせずに Java バイナリのみをフォルダ (例:/usr/bin/) にハード コピーしたか、Java バイナリのハードリンクのみをフォルダ (例:/usr/bin/) に作成しました。 .
# cp [JAVA_HOME]/jre/bin/java /usr/bin/
Java ランチャ バイナリが JRE/JDK のファイルを見つけられない場合、JVM の起動に失敗します。 libjli.so は、Java バイナリに動的にリンクされます。これは、Java ランチャーがロードを試みる最初のライブラリーの 1 つです。 Java ランチャーが適切に起動するには、Java に関連付けられているすべてのライブラリを読み取れる必要があります。
これを解決するには 2 つの方法があります:
解決策 1
/usr/bin フォルダーから Java を呼び出す場合は、ハードリンクまたはコピーの代わりにシンボリック リンクを作成します。
# sudo ln -s [path to the JRE's java binary] /usr/bin/java注意 :コマンド「update-alternatives」をサポートする Linux システムでは、シンボリック リンクを作成する代わりに、以下の解決策 2 を使用する必要があります。
解決策 2
以下の投稿に従って update-alternatives コマンドを使用して、正しい Java パスを設定してください。
「java」コマンドは、インストールされている JVM を実行しませんケース 2 の解決策
ここには 2 つのシナリオがあります:
シナリオ 1
「セットキャップ 」コマンドを使用して、特権のないユーザーに特別な権限を許可する適切な権限を Java バイナリに付与しました。たとえば、1024 未満のポートを開くには:
# setcap cap_net_bind_service=+ep/bin/java
実行可能ファイルの特権を上げると、ld.so としてよく知られているランタイム ローダー (rtld) は、信頼されていないパスのライブラリとリンクしません。これが ld.so(1) の設計方法です。そのような実行可能ファイルを実行する必要がある場合は、昇格した実行可能ファイルの関連ライブラリへのパスを ld.so の信頼できるパスに追加する必要があります。
シナリオ 2
JDK/JRE が別のユーザー アカウント (root など) でインストールされ、libjli.so のみ、または JDK または JRE ディレクトリ構造全体から、全世界の読み取りアクセス許可が明示的に削除されました。例:
# chmod -R o-r [JAVA_HOME]
Java を起動するユーザーが libjli.so ライブラリを読み取る権限を持っていない場合、Java は失敗します。これは、libjli.so が Java バイナリに動的にリンクされているためです。 Java が適切に起動するには、動的にリンクされたすべてのライブラリを読み取れる必要があります。
シナリオ 1 のソリューション
ここには 2 つの解決策があります:
1. Java バイナリから機能を再度削除します。
# setcap -r [JAVA_HOME]/bin/java
java -version が現在機能していることを確認します:
$ [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. libjli.so へのパスを指定して、次のようなファイルを作成します。
$ cat /etc/ld.so.conf.d/java.conf [JAVA_HOME]/jre/lib/amd64/jli注意 :32 ビット JRE を使用する場合は、amd64 を i386 に置き換えます。
これにより、ld.so が使用する信頼できるユーザー パスにそのパスが追加されます。ランタイム キャッシュの構築が必要になる場合があります。次の手順を実行して、ld.so が認識しているかどうかを確認します。コマンドは root として実行する必要があります。再起動が必要な場合があります。
# ldconfig | grep libjli libjli.so -> libjli.so .......
java -version が現在機能していることを確認します:
$ [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 のソリューション
ユーザーが JDK/JRE ディレクトリの libjli.so およびその他のファイルを読み取れるように、読み取り権限を復元します。例:
# chmod -R o+r [JAVA_HOME]
java -version が現在機能していることを確認します:
$ [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)