logrotate個別ガイド｜更新日：2026年9月6日

logrotateのcopytruncateとpostrotateの違い｜安全な選び方

ログを書き続けるアプリでは、ローテーション後に新しいログを開かせる方法が重要です。copytruncateとpostrotateは動作もリスクも異なります。

このページで分かること

copytruncateの動作と欠損リスク
rename＋postrotateの基本
アプリ別の選び方と確認方法

先に結論

このページの役割： このページは、ログを開き続けるアプリでどちらの方式を選ぶかという判断に特化しています。設定値全体はlogrotate設定ガイドを参照してください。

アプリがHUPやreloadでログを再オープンできるなら、通常はrename・create後にpostrotateで再オープンさせる方法を優先します。再オープンできない場合に限り、copytruncateの短い欠損区間を理解して検討します。

copytruncateとは？ postrotateとの違いを先に整理

方式	ログファイルの扱い	向いている場面	主な注意点
`copytruncate`	現在のログをコピー後、元ファイルをその場で0バイトに切り詰める	アプリにログ再オープンを通知できない場合の選択肢	コピーからtruncateまでの短い間にログを失う可能性。`create`は実質不要
通常ローテーション + `postrotate`	ログをrename等で切替え、必要ならアプリへ再オープン通知	アプリがsignal/reload等でログを開き直せる場合	通知コマンド・権限・サービス名が正しいか確認が必要

選び方：copytruncate を「postrotateを書かなくて済む簡単な方法」として一律に選ばず、アプリがログを再オープンできるかを先に確認します。

logrotate設定をレビューする

設定を貼り付けて、copytruncate、postrotate、create、su、圧縮設定の注意点を確認できます。

logrotateレビューを使う

通常のローテーション動作

通常のlogrotateは、現在のログファイルをrenameして退避し、必要に応じてcreateで新しいログファイルを作成します。ただし、アプリが古いファイルディスクリプタを保持したままだと、rename後も退避済みファイルへ書き続けます。

copytruncateの仕組み

copytruncateは現在のログをコピーした後、元ファイルをその場で0バイトへ切り詰めます。アプリは同じファイルを開き続けられるため、ログ再オープン機能がないアプリでも使えます。

/var/log/example/app.log { daily rotate 14 compress copytruncate }

欠損の可能性： コピー完了からtruncateまでの短い間に書き込まれたログは、コピー先にも元ファイルにも残らない可能性があります。高頻度・重要ログでは影響を評価してください。

copytruncateでは元ファイルを使い続けるため、通常はcreateで新しいファイルを作る処理は意味を持ちません。

postrotateによる再オープン

アプリがシグナルやreload操作でログを再オープンできる場合は、通常のrename後にpostrotateで再オープンを依頼します。

/var/log/example/app.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 appuser appgroup sharedscripts postrotate /bin/systemctl kill -s HUP example.service endscript }

この例では新しいログを作成し、サービスへHUPを送って新しいファイルを開かせます。実際にHUPへ対応しているかはアプリの公式仕様で確認してください。

失敗を隠さない： postrotateの通知コマンドへ安易に || true を付けると、再オープン失敗を見逃す原因になります。対象アプリがHUPやreloadに対応していることを公式資料で確認し、テスト時は終了コードとローテーション後の書き込み先を確認してください。

違いの比較

観点	copytruncate	rename＋postrotate
アプリの再オープン対応	不要	必要
短時間のログ欠損	起こり得る	正しく再オープンできれば避けやすい
新規ファイルの権限	元ファイルを継続利用	`create`で指定
失敗ポイント	コピー時間・欠損区間	シグナル・reload・権限・サービス名
向くケース	再オープン機能がないアプリ	再オープン対応アプリ

設定例を選ぶ基準

アプリがログ再オープンに対応しているか公式資料で確認
対応しているなら、推奨されるシグナルまたはreloadコマンドを使う
新規ログの所有者・グループ・モードを確認
対応していない場合のみcopytruncateの欠損リスクを評価
高負荷時にテストし、書き込み継続先を確認

適用前の確認

sudo logrotate -d /etc/logrotate.d/example sudo logrotate -f /etc/logrotate.d/example ls -l /var/log/example/ lsof /var/log/example/app.log /var/log/example/app.log.1 2>/dev/null

強制実行： -fは実際にローテーションします。本番では退避、ディスク容量、アプリの再オープン方法を確認してから実行してください。

そもそもローテーションされない

copytruncateの選択以前に、設定読込・条件・state・定期実行を確認します。

ローテーションされない原因を確認 →

切替後にアプリが書かない

旧ファイルを握り続ける、createの所有者、postrotate失敗などを確認します。

書込み停止を切り分け →

設定をレビューする

選んだ方式を含め、実行前の注意点を確認します。

logrotate設定をレビュー →