Linux（Ubuntu Pro）環境活用 ライフハックスクリプト

Linux（Ubuntu Pro）環境活用 ライフハックスクリプト
Linux
Ubuntu Pro

0
投稿日 2026年08月19日

曖昧な「ストレージが重い・空きがない」という事象は、原因の特定が難航しやすい障害の一つです。巨大ログの突発的増殖、プロセスによって掴まれた削除済みファイル（Ghost Files）、ext4/XFSでのインデックス（i-node）枯渇、Snapパッケージの旧バージョンキャッシュの累積など、原因を定量的に特定せずに場当たり的なファイル削除を行っても根本解決には至りません。

Linux / Ubuntu Pro環境において、単なる df や du コマンドの実行を超えた「ファイル操作・容量診断レシピ」と、一括で一次切り分けを行う自動化シェルスクリプト『disk-doctor.sh』を提案します。

---

1. 階層的容量測定による「闇容量」の可視化

標準の du -sh * をルートディレクトリ配下で無作為に実行すると、/proc や /sys などの仮想ファイルシステム、別パーティションのネットワークマウント（NFS等）まで再帰走査してしまい、処理の遅延や正確性の喪失を招きます。

高速かつ正確な診断には、ファイルシステム境界を超えない指定（-x オプション）と、並行処理や find を組み合わせたセグメント解析が必要です。

高速なディレクトリ別容量ランキングの算出

# ファイルシステム境界を越えずに1階層目のディレクトリ容量トップ10を抽出（並列処理・エラー抑制）
sudo du -hx --max-depth=1 / 2>/dev/null | sort -rh | head -n 11

出力例と判定基準

45G    /
18G    /var
12G    /usr
8.5G   /home
4.1G   /snap
...

• /var 配下の不自然な増大：/var/log 内のローテーション破綻（journald やアプリケーションログ）、/var/cache/apt のパッケージキャッシュ溜まり、/var/lib/docker などのコンテナイメージ肥大化が原因の筆頭候補です。
• /snap 配下の増大：Ubuntu Pro環境特有の事象として、Snapパッケージ更新時に「旧バージョンのリビジョン」が複数保持され、ディスクを圧迫している可能性があります。

---

2. I/Oボトルネックとロック状態の特定

容量不足だけでなく「rm でログを消したのに df の空き容量が増えない」「特定ディレクトリへの書き込みでI/O待ち（iowait）が発生する」現象は、プロセスによる削除済みファイルの保持や i-node枯渇 が起因します。

削除済みファイルのプロセス保持とファイルシステム状態の検査

# 1. 削除されたがプロセスにオープンされたまま（容量を解放していない）ファイルを特定
sudo lsof +L1

# 2. i-node（ファイル数上限）の使用状況確認
df -i -h -x tmpfs -x devtmpfs

# 3. systemd journald ログが消費しているディスク容量の確認
journalctl --disk-usage

取得パラメータ / コマンド意味と診断時の判定基準

コマンド / パラメータ	意味と診断時の判定基準
lsof +L1 (または `lsof	grep deleted`)
df -i (IUse%)	ディスクバイト容量に余裕があっても IUse% が 100% の場合、セッションファイルや微小ログの大量生成で「ファイルが作れない」障害が発生。
journalctl --disk-usage	システムログの総消費量。/etc/systemd/journald.conf の SystemMaxUse 設計見直しの指標とする。

---

3. 障害時にワンショットで一次切り分けを行う「自動化シェルスクリプト」

緊急時にストレージの全体像（パーティション状態、i-node、削除済み保持ファイル、巨大ファイル上位15件、Ubuntu固有のキャッシュ状態）を網羅的に取得し、ログファイルへ保存する統合診断スクリプトです。

ワンステップ診断スクリプト：disk-doctor.sh

#!/usr/bin/env bash
#
# SYNOPSIS:
#   Linux (Ubuntu Pro) 用 ディスク・ファイルシステム一次診断スクリプト
#

set -u

LOG_PATH="/tmp/disk_diag_$(date +'%Y%m%d_%H%M%S').log"

# root権限チェック
if [ "$EUID" -ne 0 ]; then
    echo "エラー: このスクリプトは sudo または root 権限で実行してください。" >&2
    exit 1
fi

exec &> >(tee -a "${LOG_PATH}")

echo "=========================================="
echo " Storage Diagnostic Report - $(date)"
echo " Host: $(hostname) ($(lsb_release -ds 2>/dev/null || cat /etc/os-release | grep PRETTY_NAME | cut -d= -f2))"
echo " Kernel: $(uname -r)"
echo "=========================================="

echo -e "\n[1. Volume & Partition Status (Disk Space & Inode)]"
echo "--- Storage Capacity ---"
df -h -T -x tmpfs -x devtmpfs -x squashfs
echo -e "\n--- Inode Usage ---"
df -i -T -x tmpfs -x devtmpfs -x squashfs

echo -e "\n[2. Deleted but Open Files (Ghost Space Leak)]"
DELETED_FILES=$(lsof +L1 2>/dev/null | head -n 15)
if [ -n "$DELETED_FILES" ]; then
    echo "$DELETED_FILES"
else
    echo "No deleted open files found."
fi

echo -e "\n[3. Top 15 Largest Files in Root Filesystem]"
find / -xdev -type f -size +10M -exec du -h {} + 2>/dev/null | sort -rh | head -n 15

echo -e "\n[4. Ubuntu / System Specific Cleanup Targets Summary]"
# APT Cache
if [ -d "/var/cache/apt/archives" ]; stream
then
    APT_SIZE=$(du -sh /var/cache/apt/archives 2>/dev/null | cut -f1)
    echo "APT Package Cache Size: ${APT_SIZE}"
fi

# Snap Cache
if command -v snap &>/dev/null; then
    SNAP_SIZE=$(du -sh /var/lib/snapd/snaps 2>/dev/null | cut -f1)
    echo "Snap Package Storage Size: ${SNAP_SIZE}"
fi

# Systemd Journal Logs
if command -v journalctl &>/dev/null; then
    echo -n "Journald Log Usage: "
    journalctl --disk-usage 2>/dev/null
fi

# Temp Directories
echo "Temp Directories Size:"
du -sh /tmp /var/tmp 2>/dev/null

echo -e "\n[5. Recent Storage & I/O Errors (dmesg & Kernel Logs)]"
dmesg -T -l err,crit,alert,emerg 2>/dev/null | grep -iE 'ata|scsi|nvme|ext4|xfs|btrfs|I/O' | tail -n 10 || echo "No critical I/O errors found in dmesg."

echo "=========================================="
echo "Diagnostic complete. Saved to: ${LOG_PATH}"

実行方法

# スクリプトに実行権限を付与して管理者権限で実行
chmod +x disk-doctor.sh
sudo ./disk-doctor.sh

---

決定論的アプローチによるストレージ管理

「容量が足りないから適当に /var/log を消す」という対症療法は、根本原因（ロギング設計の破綻、削除プロセスによるファイルハンドルの掴みっぱなし、Snapリビジョン管理の未設定、i-node枯渇）の隠蔽につながります。

• L1（物理・ボリューム・インデックス層）：df -h および df -i によるディスク・i-node枯渇率とファイルシステム種別（ext4/XFSなど）の検証
• L2（ファイルツリー構造層）：-x オプションを付けた du や find による安全かつ高速な巨大ファイル・Ubuntu特有キャッシュ（APT/Snap/Journal）の特定
• L3（カーネル・プロセス層）：lsof +L1 による「消したのに開放されない領域」の判定と、dmesg によるI/Oエラーログの解析

Linuxが提供するネイティブコマンド群とカーネル情報を組み合わせることで、勘に頼らない再現可能な障害解析が可能になります。