logrotateでtruncateを使うべきケース・使うべきでないケース【実務判断ガイド】

Linux運用でログ肥大化対策として必ず登場するのが

logrotate の copytruncate（truncate）

ですが、

「とりあえず使う」は非常に危険

です。

本記事では、

• truncateとは何をしているのか
• 使うべきケース
• 絶対に避けるべきケース
• 正しい代替策

を、実務障害事例ベースで解説します。

logrotateの基本動作を整理

logrotateはログファイルに対して以下を行います。

• ローテーション（世代管理）
• 圧縮
• 削除

通常の安全な流れは以下です。

1. ログファイルをリネーム
2. 新しいログファイルを作成
3. アプリに再オープンさせる

これを破壊的に簡略化したのが truncateです。

copytruncate（truncate）とは何か

logrotate設定例：

/var/log/app.log {
  daily
  rotate 7
  copytruncate
}

copytruncateは以下を行います。

• ログファイルをコピー
• 元ファイルのサイズを0にする

ファイル自体は削除・リネームされません。

そのため、

ログを書いているプロセスを止めずに回せる

というメリットがあります。

truncateが生まれた理由（背景）

本来、ログローテーションは

アプリがSIGHUPなどでログを再オープンできる

ことが前提です。

しかし現実には、

• 再オープン機能がない
• 再起動できない
• レガシーアプリ

が多く存在します。

その妥協策が truncate です。

truncateを使うべきケース（限定）

① ログ再オープン非対応アプリ

以下の条件をすべて満たす場合のみ許容されます。

• SIGHUP未対応
• 再起動不可
• ログ欠損リスクを許容

② 一時的な応急処置

ディスク逼迫で

「今すぐ空けないと死ぬ」

状況では、暫定措置として有効です。

③ テスト環境・検証環境

本番ではなく、

• ログ精度が重要でない
• 障害影響が小さい

環境では許容されます。

truncateを使ってはいけないケース（重要）

① ログ欠損が致命的なシステム

• 金融
• 監査対象システム
• セキュリティログ

truncateは

コピー中に書かれたログを確実に失います。

② 高頻度ログ出力アプリ

• Webサーバ
• アクセスログ大量出力

この場合、

欠損ログが大量発生

します。

③ マルチプロセス／マルチスレッド

複数プロセスが同時に書き込む場合、

ログ破損・順序崩壊

が発生します。

truncateが引き起こす典型障害

• ログが途中で消える
• 障害解析ができない
• 証跡が残らない
• 監査NG

「容量は空いたが、後で詰む」

典型的な負債系設定です。

正しい代替策（推奨）

① postrotate + SIGHUP

/var/log/app.log {
  daily
  rotate 7
  postrotate
    systemctl reload app.service
  endscript
}

最も正しい方法です。

② アプリのログ再オープン対応

最近のアプリは

• SIGHUP
• USR1

でログを開き直せます。

③ stdout / journald に寄せる

ログファイルを捨て、

• systemd-journald
• ログ集約基盤

に送るのも有効です。

truncateと「削除しても容量が空かない」問題の関係

truncateは

「削除しない」ため、inode問題を回避できます。

しかしこれは、

正しい設計の代替にはなりません。

根本解決は、

• プロセス管理
• ログ再オープン設計

です。

実務判断フローチャート（簡易）

• SIGHUP対応？ → YES：truncate不要
• ログ欠損OK？ → NO：truncate禁止
• 本番？ → YES：慎重に

まとめ

copytruncateは

「便利な裏技」ではなく「最後の手段」

です。

安易に使うと、

• 障害解析不能
• 監査失敗
• 後工程で大事故

につながります。

本記事を、

「truncateを使うか迷った時の判断基準」

として活用してください。