web-dev-qa-db-ja.com

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

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

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

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

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

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

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

logrotate -dhttp://Pastebin.com/e6AshtGq

ls -l /var/loghttp://Pastebin.com/Y2A4Li59

cat /etc/logrotate.confhttp://Pastebin.com/1h7Uwctr

ls -l /etc/logrotate.dhttp://Pastebin.com/NvUAeszM

debianlogrotatedebian-squeeze
8
fabrik

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
8
user9517

同様の問題がありましたが、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再び、うまくいきました。

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

10
Frog23

分かった分かった。 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ファイルである可能性があります。構文が間違っている場合に見つけることができる出力が提供されないため、そのファイルの構文を二重または三重チェックすることを意味します。構文検証に失敗した後、静かに終了します。

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

2
Smirk

競合するログローテーション設定パラメータを確認します!!

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

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

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

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

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

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

1
BruceJo

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

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

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

1
rogerdpack

これは、サービスの変更に伴って頻繁に発生し、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コマンドに追加し、そのフォルダーで何が起こるか（ある場合）を確認します。

1
DBrown