Fedoraサーバーでの頻発するリブートとjournalのエラーへの対処方法

最近，Fedora38からFedora41へとアップデートを行ったサーバーで，3～5時間に1回程度，勝手にリブートがかかるという問題が発生しました。この問題の原因を調査し，最終的に解決した方法について記録します。

問題の概要

はじめに，リブートのタイミングがcrontabで実行されるジョブの時間と一致していたため，定期実行されるプログラムが原因と考えました。しかし，問題を掘り下げるうちに，以下の状況が判明しました。

  1. SELinuxをPermissiveモードに設定すると，さらにリブート頻発時間が短くなる
  2. リブート直前のログが不完全で，途中で切れている（/var/log/messages）
  3. journalctl --verifyコマンドでジャーナルログの破損を検出

エラーログの確認

リブート直前のログは以下のように記録されていました：

Nov 14 06:40:11 server audit[1]: SERVICE_STOP pid=1 uid=0 auid=xxxx ses=xxxx msg='unit=user-runtime-dir@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 06:40:11 server systemd[1]: Removed slice user-0.slice - User Slice of UID 0.
Nov 14 06:40:11 server systemd-logind[748]: Removed session 548.
Nov 5 15:13:30 server su[1540]: (to root) user on pts/0
Nov 5 15:19:00 server smbd[2128]: [2024/11/05 15:19:00.003114, 0] ../../source3/smbd/msdfs.c:97(parse_dfs_path_strict)

journalctl --verifyを実行すると，次のエラーが確認されました：

71ce810: Data object references invalid entry at 10598418
File corruption detected at /var/log/journal/xxxx/system.journal:274295040 (of 276824064 bytes, 99%).
FAIL: /var/log/journal/xxxx/system.journal (不正なメッセージです)
PASS: /var/log/journal/xxxx/user-1000.journal

どうやら，ジャーナルログが破損しており，これが原因でjournaldやrsyslogの動作に影響を与えている可能性が高いことがわかりました。

試行錯誤と対策

ログの破損を防ぐため，以下の対応を試みました。

  1. 過去のジャーナルログを削除
journalctl --rotate
journalctl --vacuum-time=1s
  1. ジャーナルログのサイズ制限
    /etc/systemd/journald.confを編集して以下の設定を追加：
SystemMaxUse=2G
SystemMaxFileSize=500M

設定変更後にサービスを再起動：

systemctl restart systemd-journald
  1. ハードウェア検査
    メモリーテスト（Memtest）やSSDのSMART情報をチェック（smartctl -x /dev/sda など）しましたが，特に異常はありませんでした。
  2. Fedoraの再インストール
    上記の対応を行っても，症状が改善されることはありませんでした。そのため，Fedoraを再インストールしました。再インストール後も同様の症状があり，解決しませんでした。

最終的な解決策：サーバー本体（メインボード）の交換

上記の対応を行っても，症状が改善されることはありませんでした。そのため、最終的にメインボードの交換をしました。サーバーの交換後，以下を確認しました：

  • journalctl --verifyでログ破損なし
  • リブートが発生しない

これにより，ハードウェア自体に何らかの故障があった可能性が高いと結論付けました。

再発防止のための設定

再インストール後は，以下のポイントを守ることで，再発を防ぐ体制を整えました。

  1. ジャーナルログの定期チェック
journalctl --verify
  1. バックアップの確保
    システムの変更前に設定ファイルや重要なデータをバックアップ
  2. ハードウェア診断の定期実施
    定期的にメモリやディスクの健全性を確認

まとめ

今回の問題では，サーバー本体の交換が最終的な解決策となりました。おそらく，SSDやメモリー以外のメインボード等のハードウェアが故障した可能性が高いと推測されます。同様の問題に遭遇した際には，まずジャーナルログの破損を疑い，ハードウェアの状態を慎重に確認することも視野に入れる必要がありそうです。