web-dev-qa-db-ja.com

rsyslogが/ var / logをいっぱいにすると、システムがダウンします

プロセスが失敗して_/var/log_のログが大きくなり、最終的にパーティション全体がいっぱいになることがあります。

Postfixの設定が間違っているためにサーバーで1回、USBプリンターが原因でデスクトップで1回発生しました(正確に何が問題なのかはわかりませんが、_(hp) did not claim interface 1 before use_で満たされたログだけがわかります)。

根本的な原因はロガーではなくアプリケーションであることを知っています。しかし、この弱点が恥ずかしいと思わずにはいられません。特にデスクトップでは、システムパーティション全体を埋めるプリンターにより、ユーザーは次回の実行時にGUIを読み込めなくなります(_/tmp_にはスペースがありません)。

  • logrotateは毎日または毎週実行されるため、答えにはなりません。

  • rsyslogには max-size、action-on-max-size 設定オプションがありますが、それは簡単ではないようで、ドキュメント自体によると、将来のリリースでは機能しなくなる可能性があります。

  • ただし、専用パーティションに_/var/log_を配置すると、これが発生しなくなります。

私の知る限りでは、_/var/log_の個別のパーティションがこれに対する唯一のソリューションです。私はこれが推奨されることを時々見ましたが、たとえば、Debianインストーラのデフォルトではありません。それでいいの?

これを回避する簡単な方法は他にありますか? _/var/log_ディレクトリ、または少なくともrsyslog?に最大サイズを提供する方法

この問題は、デフォルトでアクティブになる保護メカニズムを正当化するほど頻繁ではありませんか? (私は特に、ユーザーが自分でこれを処理することができないはずのホーム/デスクトップインストールを考えています。)

編集:SystemLogRateLimit

ジュリーペレティエの回答 のおかげで、私は レート制限メカニズム をrsyslogで発見しました。これは、このニーズに正確に応え、デフォルトでアクティブにする必要があります。

(5.7.1以降)使用可能な入力レート制限があり、ログプロセスの乱暴な実行の問題から保護されます。 SysSock.RateLimit.Interval * SysSock.RateLimit.Burstログメッセージよりも多くが同じプロセスから発行される場合、SysSock.RateLimit.Severity以下のメッセージはドロップされます。

ただし、PIDが変更された場合、SystemLogRateLimitは機能しません。 ドキュメントページ は、レート制限機能をテストする方法を説明し、

レート制限は、同じPIDが指定されている場合にのみ機能します

これがここでは当てはまらない理由だと思います。

私のデスクトップ:

_Jul 25 21:34:36 bouzin kernel: [46038.140491] usb 1-5: usbfs: process 12126 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140546] usb 1-5: usbfs: process 12127 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140606] usb 1-5: usbfs: process 12128 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140675] usb 1-5: usbfs: process 12129 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140740] usb 1-5: usbfs: process 12130 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140809] usb 1-5: usbfs: process 12131 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140868] usb 1-5: usbfs: process 12132 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140928] usb 1-5: usbfs: process 12133 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.140988] usb 1-5: usbfs: process 12134 (hp) did not claim interface 1 before use
Jul 25 21:34:36 bouzin kernel: [46038.141046] usb 1-5: usbfs: process 12135 (hp) did not claim interface 1 before use
_

私のサーバー:

_Jul  5 13:37:45 server postfix/smtpd[426]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
Jul  5 13:37:45 server postfix/smtpd[437]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
Jul  5 13:37:45 server postfix/smtpd[426]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
Jul  5 13:37:45 server postfix/smtpd[437]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail.SERVER.TEST>
_

したがって、各ログ行は異なるプロセスによって書き込まれるため、IIUC rsyslogのレート制限機能はここでは関係ありません。

編集2:ディレクトリサイズを制限する

仮想ファイルシステムを使用して_/var/log_のサイズを制限しました(推奨される ここ )。

次回Linuxをインストールするときに、別のパーティションをセットアップするかもしれません。

私はこれを答えではなく回避策と考えているので、私は今この質問を開いたままにしています。

7
Jérôme

rsyslogには、デフォルトでimuxsockモジュールによるレート制限オプションが含まれています。

デフォルトでは5秒あたり200メッセージですが、モジュールのロード後に次のように設定することで簡単に変更できます。

$SystemLogRateLimitInterval 5
$SystemLogRateLimitBurst 200

$SystemLogRateLimitIntervalは秒単位の間隔(増加する必要があります)および$SystemLogRateLimitBurstは、その間隔中にアプリケーションが許可するメッセージの最大数です(これは減らす必要があります)。

更新:エラーが原因でsyslogにさまざまなプロセスIDが殺到しているという事実に関する更新に基づいて、デーモンがこれらを効率的に処理する実際的な方法はありません。

したがって、最大ファイルサイズのログローテーションルールを変更することが唯一の可能な解決策です。 (通常のログローテーションプロセスに従って)圧縮されると、これらの大きなファイルは、内容の反復性のために非常に小さくなります。

5
Julie Pelletier