Linux 実践コマンドリファレンス｜現場の「調べる・直す」ユースケース逆引き

本記事は、Linuxサーバーで「調べる・直す」ときの逆引きリファレンスです。ファイルと権限、ログ調査、プロセス/リソース、サービスとログ、ネットワーク、そして障害の初動切り分けまで、コピペで動く断片と最後の1画面早見表でまとめます。未経験〜駆け出しの方が、現場で手が止まらないことを目指しました。

01前提 — シェル・パイプ・リダイレクト・ヘルプ

この記事は「Linuxで調べる・直す」ときの逆引きリファレンスです。1つひとつの網羅解説ではなく、やりたいこと → コマンド → 注意点の順でまとめます。体系的に基礎から学びたい方は、まず教科書記事の Linux 章 クラウドエンジニアの土台（TCP/IPとLinux基礎） をどうぞ。ここはその実践編です。

操作の窓口がシェルです。多くの環境（Amazon Linux 2023 / Ubuntu など）で標準は bash。コマンドの出力を次のコマンドへ渡す「つなぎ方」を先に押さえると、以降がぐっと楽になります。

command | filter      # パイプ: 左の出力を右の入力へ渡す
command > out.txt     # 標準出力をファイルへ上書き保存
command >> out.txt    # 追記（既存を消さない）
command 2> err.txt    # 標準エラーだけをファイルへ
command > all.txt 2>&1 # 標準出力とエラーをまとめて保存
command 2>&1 | less   # 出力＋エラーをまとめてページャで読む

例えば「ログから ERROR を含む行だけ、件数を数える」なら次のように部品を組み合わせます。

grep -i error app.log | wc -l

使い方に迷ったら、記憶に頼らずその場で確認します。

• コマンド --help … 主要オプションを1画面で（まずこれ）
• man コマンド … 詳細マニュアル。/語で検索、qで終了
• apropos 語 / man -k 語 … コマンド名をキーワードから逆引き

02ファイルと権限 — ls -l の読み方 / chmod / find / tar

ls -l の1行は情報の宝庫です。左から「種別＋権限／リンク数／所有者／グループ／サイズ／更新日時／名前」。まず先頭10文字の読み方を身につけます。

-rw-r--r--  1 ec2-user ec2-user  1240 Jul 15 10:22 app.conf
drwxr-xr-x  2 root     root      4096 Jul 10 09:00 logs
└┬┘└┬┘└┬┘└┬┘
 │  │  │  └ その他ユーザー(other)の権限
 │  │  └ グループ(group)の権限
 │  └ 所有者(owner)の権限
 └ 種別: - =ファイル / d =ディレクトリ / l =シンボリックリンク

権限は r=読み(4) / w=書き(2) / x=実行(4は違う、x=1) の組み合わせ。数値表記では owner/group/other を3桁で表します。例：644＝rw-r--r--、755＝rwxr-xr-x、600＝rw-------。

ファイルを探すのは find。名前・サイズ・更新日で絞り込み、見つけたものへ処理まで一気にできます。

# カレント以下で名前が *.log のファイル
find . -name '*.log'
# /var/log 以下で100MB超（大きいファイル探し）
find /var/log -type f -size +100M
# 過去1日以内に更新されたファイル
find . -type f -mtime -1
# 見つけた .tmp をまとめて削除（-exec。実行前にまず -print で確認）
find . -name '*.tmp' -print
find . -name '*.tmp' -exec rm {} +

まとめる・展開するのは tar。よく使う2つだけ覚えれば足ります。

tar czf logs.tar.gz logs/     # c=作成 z=gzip f=ファイル名 → 圧縮
tar xzf logs.tar.gz           # x=展開（.tar.gz / .tgz）
tar xJf pkg.tar.xz            # .xz は大文字J（xzf ではなく xJf）
tar tzf logs.tar.gz           # t=中身を展開せず一覧確認

03テキスト調査 — grep / less / tail -f / sed・awk / sort・uniq

調査の主役はログや設定ファイルの中身を絞り込む作業です。まずは grep。

grep -i error app.log          # 大文字小文字を無視して error を含む行
grep -n error app.log          # 行番号つき
grep -rin 'timeout' /etc/      # -r 再帰 -i 無視 -n 行番号（設定の在りかを探す）
grep -v '^#' nginx.conf | grep -v '^$'  # コメントと空行を除いて実質設定だけ表示
grep -c error app.log          # 該当"行数"を数える

大きなファイルは less でページャとして開きます。全部を cat で流すより安全で速いです。

• /語 … 前方検索（nで次へ、Nで前へ）
• G … 末尾へ / g … 先頭へ
• q … 終了 / F … 末尾に張り付いて追尾（tail -f相当、Ctrl-cで解除）

リアルタイムに流れるログを見るなら tail -f。デプロイ直後やリクエストを打ちながらの確認に必須です。

tail -f /var/log/nginx/access.log            # 末尾を追尾表示
tail -n 200 app.log                          # 直近200行だけ
tail -f app.log | grep --line-buffered 500   # 追尾しつつ 500 を含む行だけ

sed/awk は奥が深いですが、現場ではごく一部で足ります。置換と列の抜き出しだけ覚えておきましょう。

sed -n '100,120p' app.log        # 100〜120行目だけ表示
sed 's/foo/bar/g' in.txt         # 各行の foo を bar に（画面出力。上書きしない）
awk '{print $1}' access.log      # 空白区切りの1列目（例: アクセス元IP）
awk -F',' '{print $3}' data.csv  # カンマ区切りの3列目

集計の定番が sort | uniq -c | sort -rn。アクセスログから「多い順」を出す型です。

# アクセス元IPを多い順に集計（上位10件）
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head
# 出現行数を数える
wc -l access.log

04ユースケース：プロセスとリソースを見る

「重い・落ちた・容量がない」の初動で使う道具です。まず何がリソースを食っているかを見ます。

ps aux                       # 全プロセスを一覧（USER/PID/%CPU/%MEM/COMMAND）
ps aux --sort=-%cpu | head   # CPU使用率の高い順トップ
ps aux --sort=-%mem | head   # メモリ使用率の高い順トップ
top                          # リアルタイム監視（q で終了、1 でコア別表示）
htop                         # 見やすい対話版（未導入なら dnf/apt で追加）

暴走プロセスを止めるときは、まず穏やかなシグナルから。いきなり -9 は最後の手段です。

kill 12345          # PID 12345 に終了要求（SIGTERM）。後片付けの猶予を与える
kill -9 12345       # 強制終了（SIGKILL）。効かない時の最終手段
pkill -f myapp.py   # コマンド名の一部で止める（対象を必ず ps で確認してから）

ディスクとメモリの空きはこの3つ。ディスク満杯はサービス停止の頻出原因です。

df -h                    # ファイルシステムごとの使用率（-h=人間向け単位）
du -sh *                 # カレント直下の各項目の合計サイズ（重いディレクトリ探し）
du -sh /var/* 2>/dev/null | sort -h | tail   # /var 配下で大きい順
free -h                  # メモリ・スワップの空き

どのプロセスがポートを掴んでいるか、あるいはファイルを開いたまま消せないかは lsof。

lsof -i :8080        # 8080番ポートを使っているプロセス
lsof -i -P -n        # 通信中のソケット一覧（名前解決せず速く）
lsof /var/log/app.log  # そのファイルを開いているプロセス

05ユースケース：サービスとログ（systemd / journalctl）

最近のLinuxはサービス管理に systemd を使います。状態確認と再起動、そしてログ参照の3つを押さえます。

systemctl status nginx        # 状態・直近ログ・PIDをまとめて確認（まずこれ）
sudo systemctl restart nginx  # 再起動（設定変更の反映）
sudo systemctl reload nginx   # 無停止で設定再読み込み（対応サービスのみ）
systemctl is-enabled nginx    # 自動起動が有効か
systemctl list-units --failed # 失敗しているサービスだけ一覧

systemd 配下のサービスログは journalctl で読みます。サービス指定＋期間指定が実戦の型です。

journalctl -u nginx                 # nginx のログ
journalctl -u nginx --since '1 hour ago'   # 直近1時間
journalctl -u nginx --since today -p err   # 今日分のうちエラー以上
journalctl -u nginx -f              # 追尾（tail -f 相当）
journalctl -xe                      # 直近のエラーを詳細つきで（初動の定番）

アプリによっては従来どおり /var/log/ にファイル出力します。主要な置き場所を覚えておくと早いです。

06ユースケース：ネットワークを調べる（ss / curl / dig / ip）

「繋がらない」を切り分ける道具です。まず自分側がポートを開けて待っているかを ss で確認します（netstat の後継）。

ss -tulpn                 # TCP/UDPのリッスン中ポートとプロセス（t=TCP u=UDP l=Listen p=プロセス n=数値）
ss -tn state established  # 確立済みのTCP接続一覧
ss -tulpn | grep 443      # 443 を誰が掴んでいるか

相手側に届くか・応答が返るかは curl と名前解決・到達性で確認します。

curl -I https://example.com/          # ヘッダだけ取得（HTTPステータス確認に最適）
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/
dig example.com +short                # 名前解決の結果（AレコードのIP）
dig @1.1.1.1 example.com              # DNSサーバーを指定して引く
ping -c 4 example.com                 # 到達性（ICMP。4回で止める）
traceroute example.com                # 経路のどこで止まるか

自分のIP・ルーティングは ip 系（ifconfig/route の後継）。

ip a       # インターフェースとIPアドレス一覧（ifconfig 相当）
ip r       # ルーティングテーブル（デフォルトゲートウェイ確認）

07ユースケース：障害の初動 —「仮説と検証」で切り分ける

初動でいちばん大事なのは、闇雲にコマンドを打たず「仮説 → 検証 → 次の一手」の型で進めることです。よくある3パターンの手順を示します。

① CPUが高い・応答が遅い

• 仮説：特定プロセスがCPUを食っている → top / ps aux --sort=-%cpu | head
• 次の一手：犯人のPIDが分かったら journalctl -u <svc> や該当ログでその時刻の異常を確認
• メモリ不足でスワップして遅い可能性 → free -h（swap が埋まっていないか）

② ディスクが満杯（書き込みエラー・サービス停止）

• 仮説：どこかが容量を食い切った → df -h で満杯のマウントを特定
• 犯人探し：sudo du -sh /var/* 2>/dev/null | sort -h | tail で大きい所を掘る
• ログの肥大が原因なら削除よりローテーションを。空きが出ないときは df -i（inode枯渇）も確認

③ 繋がらない（アクセスできない）

• 自分側：systemctl status <svc> で起動しているか → ss -tulpn でポートを開けて待っているか
• 相手側：curl -I で応答コード、dig +short で名前解決、ping で到達性
• それでも不明なら経路を疑う：AWSならセキュリティグループ／ルートテーブル、社内ならtracerouteでどこで止まるか

08早見表 — やりたいこと逆引き

迷ったらここへ。「やりたいこと」からコマンドを引ける1画面チートシートです。

09よくある質問（FAQ）