この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Linux kernelのprocfs資料と、既存の実行済みDaily-Code-Samplesを確認し、/proc/selfが誰を指すのかを安全な読み取りだけで観察します。
検証ステータス：🧪 Debian 13 / Bash 5.2.37でローカル確認済み・Ubuntu実機は未確認
/proc は普通のディスク上フォルダを並べたものではなく、カーネルがプロセスやシステム状態をファイルのような形で見せる仮想ファイルシステムです。まず自分のPIDだけを読み、/proc/self の少し意外な挙動を見ます。
まず動かす
秘密情報を含み得る /proc/*/environ は触りません。status の Name/Pid/PPid だけ読みます。
echo "[SHELL] Bash PID = $$"
echo '[OBSERVE 1] /proc/$$/status'
awk '/^(Name|Pid|PPid):/ {print}' "/proc/$$/status"
echo '[OBSERVE 2] /proc/self/status'
awk '/^(Name|Pid|PPid):/ {print}' /proc/self/status
procfsの基本はLinux kernel documentationで確認できます。
ここを見る
1つ目では Pid がBash自身の $$ と一致します。ところが2つ目は、環境によって Name: awk となり、PidもBashとは別になります。
なぜなら /proc/self の self は「コマンドを書いたシェル」ではなく、そのパスを実際に参照するプロセスを指すからです。この例では awk が /proc/self/status を開いています。
flowchart LR
B["Bash PID = $$"] --> A[awkを起動]
A --> P["/proc/self/status をopen"]
P --> K["Kernel / procfs"]
K --> R[awk自身のPidを返す]
1か所変えてみる
今度は self ではなく、明示的にBashのPIDを指定します。
cat "/proc/$$/cmdline" | tr '\0' ' ' echo
/proc/$$ なら対象PIDを固定しているため、別プロセスの cat が読んでも参照先はBashのままです。
なぜファイルのように見えるのか
procfsはカーネル内部の情報をユーザー空間へ公開するインターフェースです。status を読むとき、保存済みテキストファイルを開いていると考えるより、「カーネルが現在の状態をファイル風に見せている」と捉えると理解しやすくなります。
この考え方が分かると、ps や監視ツールの裏でLinuxがどんな情報を公開しているかを追いやすくなります。
仕事で使うなら
/proc には便利な情報が多い一方、何でも記事やログへ出してよいわけではありません。
/proc/*/environは環境変数や秘密情報を含む可能性がある他ユーザーのプロセスは権限やmount設定で見え方が変わる
一瞬で終了するPIDは観察中に消える
Linux固有の仕組みなので他OSへそのまま一般化しない
トラブル調査では、必要な項目だけを読み取る方が安全です。
GitHubサンプル
既存サンプルは [START] / [OBSERVE] / [SUCCESS] を表示し、秘密情報を読むパスを避けています。
公式情報・一次情報
まとめ
/proc/<PID> は指定したプロセスを、/proc/self はそのパスを参照しているプロセス自身を表します。小さな読み取り実験だけでも、Linuxがカーネル状態をファイル風インターフェースとして公開していることを体験できます。
