有时，某个过程会出错，日志/var/log会增长得太多，最终会填满整个分区。
由于后缀配置错误，在服务器上发生过一次，由于 USB 打印机在桌面上发生过一次（不确定到底出了什么问题，我只知道日志中充满了(hp) did not claim interface 1 before use）。
我知道根本原因不是记录器而是应用程序。然而，我不禁认为这个弱点是一种耻辱。特别是在桌面上，打印机填满整个系统分区，阻止用户在下次运行时加载 GUI（上没有空间/tmp），这对于非技术人员来说是完全的阻碍。
logrotate不是答案，因为它每天甚至每周都会起作用。rsyslog有那个最大尺寸，最大尺寸上的操作配置选项，但它似乎并不简单，根据文档本身，它可能会在未来的版本中崩溃。然而，放置
/var/log专用分区可以防止这种情况发生。
据我所知，单独的分区/var/log是解决此问题的唯一方法。我有时会看到这个建议，但它不是 Debian 安装程序中的默认设置。应该是吗？
还有其他简单的方法可以避免这种情况吗？某种方式可以为目录提供最大大小/var/log，或者至少为rsyslog？
这个问题是否频繁到足以证明默认激活的保护机制是合理的？ （我特别考虑家庭/桌面安装，用户不应该能够自己处理这个问题。）
编辑：系统日志速率限制
谢谢朱莉·佩尔蒂埃的回答，我发现了速率限制机制在 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 时我可能会设置一个单独的分区。
我暂时保留这个问题，因为我认为这是一种解决方法而不是答案。
答案1
rsyslog默认情况下，该模块包含速率限制选项imuxsock。
默认为每 5 秒 200 条消息，但可以在加载模块后通过设置以下内容轻松更改：
$SystemLogRateLimitInterval 5
$SystemLogRateLimitBurst 200
是以$SystemLogRateLimitInterval秒为单位的时间间隔（您应该增加该时间间隔），并且$SystemLogRateLimitBurst是该时间间隔内应用程序允许的最大消息数（您应该减少该时间间隔）。
更新：根据您的更新，错误正在使用不同的进程 ID 淹没您的系统日志，守护进程没有实际的方法来有效地处理这些问题。
因此，更改最大文件大小的日志轮换规则将是唯一可能的解决方案。请注意，一旦压缩（按照通常的日志轮换过程），这些大文件将变得很小，因为它们的内容是重复的。