/sbin/ldconfig -p の使い方と実務での活用法

はじめに (対象読者・この記事でわかること)

本記事は、Linuxサーバーの運用・保守を担当しているエンジニアや、開発環境構築で動的リンクに悩んでいるプログラマを対象としています。/sbin/ldconfig -p の出力が何を示しているのか、どのように活用してライブラリの検索パスやバージョン情報を確認できるかを具体例とともに解説します。これを読むことで、ライブラリの重複やバージョン不整合の原因特定がスムーズにできるようになり、システムトラブルの早期解決が可能になります。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。
- 基本的な Linux コマンド操作（ls, cat, grep など）
- 動的リンクと共有ライブラリ（.so）の概念
- システム管理者権限（sudo）の使用経験

ldconfig -p の概要と背景

ldconfig は、Linux カーネルが動的リンク時に参照する共有ライブラリキャッシュ（/etc/ld.so.cache）を生成・更新するユーティリティです。-p オプションを付けて実行すると、現在のキャッシュに登録されている全てのライブラリ名とそのフルパスが一覧表示されます。これにより、以下のような質問に答えることができます。

どのパスにどのバージョンのライブラリが存在するか
同名ライブラリが複数のディレクトリにある場合、優先順位は？
新しくインストールしたライブラリがシステムに認識されているか

ldconfig -p の出力は、実際にアプリケーションがロードするライブラリを予測する上で非常に有用です。特に、カスタムディレクトリを /etc/ld.so.conf に追加したり、LD_LIBRARY_PATH 環境変数で上書きしたりした場合に、期待通りに反映されているかどうかを検証できます。さらに、glibc のバージョンアップやパッケージ管理システム（apt, yum, pacman など）でのライブラリ更新時に、古いバイナリが新しいライブラリにリンクできない「ABI 不整合」エラーを防ぐ手段としても活用されます。

ldconfig -p の実践的な使い方

以下では、実際の運用シーンを想定しながら、ldconfig -p の出力を取得・フィルタリングし、問題解決へと導く手順を詳しく解説します。

ステップ1：基本的なコマンド実行と出力確認

Bash

$ /sbin/ldconfig -p

上記を実行すると、以下のような出力が得られます（抜粋）。

    libc.so.6 (libc6,x86-64) => /lib/x86_64-linux-gnu/libc.so.6
    libm.so.6 (libc6,x86-64) => /lib/x86_64-linux-gnu/libm.so.6
    libssl.so.1.1 (libssl1.1,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
    libcrypto.so.1.1 (libssl1.1,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    libcustom.so (mycustom, x86-64) => /opt/custom/lib/libcustom.so

ポイントは次の通りです。

左側は「ライブラリ名 (パッケージ名, アーキテクチャ)」
右側は実際にロードされるフルパス

この情報だけで、インストールされている全ライブラリの一覧と、期待通りの場所に存在するかが把握できます。

ステップ2：特定ライブラリだけを抽出する

多くの場合、全部のライブラリを眺めるよりも、対象のライブラリだけを絞り込みたい場面が出てきます。grep と組み合わせることで簡単に検索できます。

Bash

$ /sbin/ldconfig -p | grep libssl

結果例：

    libssl.so.1.1 (libssl1.1,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
    libssl.so.3   (libssl3,x86-64)   => /usr/lib/x86_64-linux-gnu/libssl.so.3

ここから、複数バージョンがインストールされていることが分かります。アプリケーションがどちらをリンクしているかを確認したい場合は、実行中のバイナリに対して ldd を併用します。

ステップ3：キャッシュを再生成して問題を解消

ldconfig -p の結果に期待したライブラリが無い、またはパスが古い場合はキャッシュが古くなっている可能性があります。以下の手順でキャッシュを再生成します。

Bash

# 1. /etc/ld.so.conf と /etc/ld.so.conf.d/*.conf を確認
$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

$ ls /etc/ld.so.conf.d/
custom.conf  # 例: /opt/custom/lib を追加

# 2. カスタムディレクトリが記載されていない場合は追加
echo "/opt/custom/lib" | sudo tee /etc/ld.so.conf.d/custom.conf

# 3. キャッシュ再生成
$ sudo /sbin/ldconfig

# 4. 再度確認
$ /sbin/ldconfig -p | grep libcustom

この流れで、ldconfig が新しいディレクトリを認識し、キャッシュに反映されます。

ステップ4：バージョン不整合のトラブルシューティング

ハマった点やエラー例

エラー: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
原因: ldconfig のキャッシュに古いパスが残っているか、LD_LIBRARY_PATH が意図せず上書きされている。

解決策

ldd でバイナリが参照しているパスを確認
bash $ ldd /usr/bin/openssl | grep libssl
必要に応じて LD_LIBRARY_PATH を一時的に設定し動作確認
bash $ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH $ ./my_app
ldconfig のキャッシュ再生成（上記ステップ3）を実施。
それでも解決しない場合は、/etc/ld.so.preload に不適切なエントリがないか確認。

ステップ5：高度なフィルタリングとスクリプト活用

大量のライブラリを扱うサーバーでは、awk や sed を駆使した自動抽出が便利です。以下は「x86-64」アーキテクチャの「lib*」系ライブラリだけを JSON 形式で出力する例です。

Bash

#!/usr/bin/env bash
/sbin/ldconfig -p |
awk '/\(.*x86-64\)/ { 
    gsub(/[[:space:]]+/, "", $1); 
    split($1, a, "("); 
    lib=a[1]; 
    split($3, b, "=>"); 
    path=b[2]; 
    printf("{\"library\":\"%s\",\"path\":\"%s\"},\n", lib, path);
}' | sed '$ s/,$//' > libs_x86_64.json

libs_x86_64.json は以下のような構造になります。

Json

[
  {"library":"libc.so.6","path":"/lib/x86_64-linux-gnu/libc.so.6"},
  {"library":"libm.so.6","path":"/lib/x86_64-linux-gnu/libm.so.6"}
  // 省略
]

この JSON ファイルは、構成管理ツール（Ansible, Chef, SaltStack）や CI/CD パイプラインでライブラリの整合性チェックに利用できます。

まとめ

本記事では、/sbin/ldconfig -p の基本的な使い方から、実務で直面しやすいトラブルの診断・解決手順までを網羅しました。

ldconfig の役割：共有ライブラリキャッシュの生成・表示
-p オプション：キャッシュに登録された全ライブラリとパスを一覧取得
実践テクニック：grep で絞り込み、キャッシュ再生成、バージョン衝突の対処、スクリプトで自動化

これらを活用すれば、ライブラリパスの不一致やバージョン不整合によるアプリケーションエラーを迅速に特定でき、システム安定性を向上させることができます。次回は、ldconfig と ld.so.conf の高度な設定例や、Docker コンテナ内でのライブラリ管理について掘り下げる予定です。

/sbin/ldconfig -p の使い方と実務での活用法📦