logrotateがログを自動的にローテーションしない

2つの異なる（i386 v AMD）Debianボックスがあり、同じ問題があります。logrotateはログを自動的にローテーションしません。私が手動でそれを強制すると、それはうまくいきます

/usr/sbin/logrotate -f /etc/logrotate.conf

しかし、それは私には大丈夫ではありません。

設定は変更されていません（少なくとも私は変更していません）。AMDボックスはフレッシュインストールですが、機能しません。

同様の問題に気づいた場合は、私を助けてください。

更新（一部のサーバー出力）：

logrotate -d http://pastebin.com/e6AshtGq

ls -l /var/log http://pastebin.com/Y2A4Li59

cat /etc/logrotate.conf http://pastebin.com/1h7Uwctr

ls -l /etc/logrotate.d http://pastebin.com/NvUAeszM

logrotateがcronによって実行されていることを確認してください。

編集：

コメントの議論から-cronが正しく機能していないようです。ユーザーなしでcrontabにcronjobがありましたが、これは、cronデーモンを再起動したときにのみ明らかになります

私のubuntuおよびcentosシステムには、/etc/cron.daily/logrotateその内容が

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

/ etc / crontabには、毎日のジョブを実行する次の行があります

25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily 

私は同様の問題を抱えていましたcrontabが、機能しており、一部のログディレクトリlogrotateは機能しましたが、一部は機能しませんでした。logrotateを手動で実行しようとすると、いくつかのエラーメッセージが表示されました。

user@server:/var/log/apache2$ sudo /usr/sbin/logrotate -f /etc/logrotate.conf
error: error creating output file /var/log/apache2/access.log.1.gz: File exists
error: error creating output file /var/log/apache2/error.log.1.gz: File exists
...

すべての*.1.gzファイルのサイズは0でしたsudo /usr/sbin/logrotate -f /etc/logrotate.conf。エラーメッセージに示されているすべてのファイルを手動で削除し、再度実行してみました。

この代替ソリューションもここで共有する必要がありますが、これは問題を検索しているときに最初に出てきた検索結果でしたが、提案されたソリューションはうまくいきませんでした。これは、私と同じ状況にいる他の人にも役立つかもしれません。

分かった分かった。5歳のスレッド。

それでも検索でかなり高くなる場合は、私が貢献して、発生した問題の解決策を提供します。logrotateジョブがサーバーの1つで自動的に処理されませんでした。ローテーションの強制はうまくいきました。毎日の回転コマンドを手動で実行した後、私は解決策を思いつきました：

( cd / && run-parts --report /etc/cron.daily )

次に、logrorateジョブの実行を停止するエラーを確認しました。

/etc/cron.daily/logrotate:
error: iptraf-ng:2 duplicate log entry for /var/log/iptraf/*.log

はい、それと同じくらい簡単です。ローテーションする同じログを定義する2つのファイル（iptrafとiptraf-ng）がありました。iptrafの競合するlogrotate定義の1つを削除するだけでうまくいきました。

rm /etc/logrotate.d/iptraf

別の問題は、/ etc / crontabファイルの失敗です。構文が間違っている場合に見つけることができる出力が提供されないため、そのファイルの構文をダブルまたはトリプルチェックすることを意味します。構文検証に失敗した後、静かに終了します。

これが誰かの時間を節約することを願っています。

OK同様の問題がありました。

「ログはローテーションされていませんか？」しかし、logrotateを手動で実行する（またはを実行する/etc/cron.dailyと、それらは正常に回転します。

したがって、cronは毎日「実行されていない」ようです。奇数。そのため、cron がデータを出力するログファイルを調べ、その特定の問題の修正について、「認証トークンが無効になりました。新しいトークンが必要です」と表示されました。こちらを参照してください

これは、サービスの変更に伴って時間の経過とともに頻繁に発生し、logrotateで使用されるオプションが編集されて、logrotateが毎日失敗することを確認しました。

アイデアを与えるために、最後の修正では、apache logrotateファイルのnotifyemptyオプションが無効になり、logrotateがすべて一緒に停止するようになりました。

これはある程度カバーされていますが、これらの問題を追跡するときに私が経験したプロセスを共有したいと思います。

1. まず、実行#/usr/sbin/logrotate -f /etc/logrotate.confしてエラーを探します（例：postfix：3 'missingok'）。
   参照しているファイルと行番号は、logrotate.dフォルダー内のファイルです。
2. 問題のファイルを編集し# vi /etc/logrotate.d/postfix、問題の原因となっているオプションを削除して、ファイルを保存します。
3. 最初の手順を繰り返して、回転が機能するかどうか、または他の問題があるかどうかを確認します。

最初のステップが単に何も出力しない場合がありますが、問題があることがわかります。サービス全体のログファイルがローテーションされていなかったため、このすべてが始まったので、その特定のサービスを探しているlogrotateプロセスを監視して、ローテーションが停止している原因を確認できます。これを行うには、verboseタグをlogrotateコマンドに追加し、そのフォルダーで何が起こるか（ある場合）を確認します。

競合するログローテーション設定パラメータを確認してください!!

私はこの問題に苦労していて、ようやくlogrotateに関するドキュメントを非常によく読みました。ここにいくつかの役立つドキュメントが見つかりました。

SizeパラメーターとRotation Intervalパラメーターの両方を指定しましたが、実際にはどちらも必要ありませんでした。私は、ローテーションがcronでスケジュールされたときに正確に実行されるようにしたいと考えていました。

1. サイズパラメータは、回転間隔を上書きします。したがって、私のログは、ローテーションされる前に、このパラメーターを超える必要がありました。（ディスクの使用について最も心配していたときに、これがどのように役立つかがわかります。しかし、それは私がそれを使用したかった方法ではありません。）
2. 回転間隔は、最後の回転がいつ発生したかをチェックし、次の回転が指定された量だけ遅れていることを確認します。しかし、その時間が発生するタイミングをどのように制御するかは不明です。これは、ローテーションが最後に発生した時間に基づいています。

したがって、Rotation IntervalとSizeパラメータを削除します。その後、強制せずにlogrotateが呼び出されるたびにローテーションを取得します。

編集：これでも完全には機能しません！ログファイルが特定のしきい値を下回っている場合、ログはローテーションされません。したがって、2分ごとにローテーションするcronジョブを実行したときに、ログはローテーションしませんでした。

を実行すると、詳細なデバッグ情報を確認できますlogrotate -d。これは非常に役立つデバッグ情報を提供します。