Linux サーバーが突然 Read-only file system に切り替わると、多くの場合アプリケーション障害が連鎖的に発生する。
この状況で最初に確認すべきなのは、アプリケーションログではなく、カーネルおよびファイルシステムのログである。

---

代表的なカーネルログパターン（原因） #

EXT4-fs error (device sda1): ext4_journal_check_start: Detected aborted journal
EXT4-fs (sda1): Remounting filesystem read-only

意味:
ext4 のジャーナルエラーが発生 → データ保護のため、カーネルがファイルシステムを強制的に Read-only で再マウントする。

---

Buffer I/O error on dev sda, logical block 123456
blk_update_request: I/O error, dev sda, sector 789012

意味:
ディスク I/O エラー → 物理ディスク、またはストレージ／ハイパーバイザ層の問題である可能性が高い。

---

アプリケーションログに現れる兆候（結果） #

touch: cannot touch '/var/run/app.pid': Read-only file system
mkdir: cannot create directory ‘/var/log/app’: Read-only file system

意味:
すでにファイルシステムは Read-only 状態である。
（※ これらのログは原因ではなく結果である点に注意）

---

dmesg に現れる決定的なシグナル #

Aborting journal on device sda1.
EXT4-fs error (device sda1)

これらのログが表示された場合 →
カーネルによる書き込みブロックの判断が完了している状態。
（再起動なしで自動的に復旧することはない）

---

直ちに確認すべきチェックポイント（コマンド） #

# 1. 現在のマウント状態を確認（ro オプションの有無）
mount | grep ' ro,'

# 2. カーネルメッセージからエラーパターンを検索
dmesg | egrep -i 'ext4|i/o error|read-only'

# 3. 最新のカーネルログを確認
journalctl -k | tail

---

要点まとめ #

• Read-only への切り替えは保護動作であり、原因ではない。
• 原因の多くは以下のいずれかである。
  • ディスク I/O エラー
  • ファイルシステムのジャーナル破損
  • ストレージサブシステムの障害
• ログに Remounting filesystem read-only が出ている場合、障害はすでに発生している状態である。

このパターンを最初に把握し、インフラ／OS レイヤーから確認することで、不要なアプリケーションレベルのデバッグを避けることができる。

🛠 마지막 수정일: 2025.12.23