Đôi khi một quá trình gặp trục trặc và các bản ghi /var/log
lớn lên rất nhiều, cuối cùng chúng lấp đầy toàn bộ phân vùng.
Nó đã xảy ra với tôi một lần trên máy chủ do cấu hình postfix sai và một lần trên máy tính để bàn do máy in USB (không chắc chắn chính xác những gì đã sai, tất cả những gì tôi biết là nhật ký chứa đầy (hp) did not claim interface 1 before use
).
Tôi biết nguyên nhân gốc rễ không phải là logger mà là ứng dụng. Tuy nhiên, tôi không thể không nghĩ rằng điểm yếu này là một sự xấu hổ. Đặc biệt là trên máy tính để bàn, nơi máy in lấp đầy toàn bộ phân vùng hệ thống sẽ ngăn người dùng tải GUI trong lần chạy tiếp theo (không có khoảng trống trên /tmp
), đây là một trình chặn hoàn toàn cho người không chuyên về công nghệ.
logrotate
không phải là một câu trả lời vì nó hoạt động hàng ngày hoặc thậm chí hàng tuần.rsyslog
có tùy chọn cấu hình kích thước tối đa, hành động trên kích thước tối đa , nhưng có vẻ như không tầm thường và theo tài liệu, nó có thể bị hỏng trong bản phát hành trong tương lai.Đặt
/var/log
trong một phân vùng chuyên dụng, tuy nhiên, sẽ ngăn điều này xảy ra.
Theo hiểu biết của tôi, phân vùng riêng biệt /var/log
là giải pháp duy nhất cho việc này. Đôi khi tôi đã thấy đề xuất này, nhưng nó không phải là mặc định trong trình cài đặt Debian. Nó phải được?
Có cách nào đơn giản khác để tránh điều này? Một số cách để cung cấp một kích thước tối đa cho /var/log
thư mục, hoặc ít nhất là rsyslog
?
Có phải vấn đề này không đủ thường xuyên để biện minh cho một cơ chế bảo vệ sẽ được kích hoạt theo mặc định? (Tôi đặc biệt nghĩ đến việc cài đặt tại nhà / máy tính để bàn, mà người dùng không có khả năng tự giải quyết vấn đề này.)
Chỉnh sửa: SystemLogRateLimit
Nhờ câu trả lời của Julie Pelletier , tôi đã phát hiện ra cơ chế giới hạn tốc độ trong rsyslog, câu trả lời chính xác cho nhu cầu này và nên được kích hoạt theo mặc định.
Có giới hạn tốc độ đầu vào khả dụng, (kể từ 5.7.1) để bảo vệ bạn trước các vấn đề của quy trình ghi nhật ký đang chạy. Nếu nhiều hơn SysSock.RateLimit.Interval * SysSock.RateLimit.Burst thông điệp nhật ký được phát ra từ cùng một quy trình, những tin nhắn có SysSock.RateLimit.Severity hoặc thấp hơn sẽ bị loại bỏ.
Tuy nhiên, SystemLogRateLimit không hoạt động nếu PID thay đổi. Các trang doc giải thích làm thế nào để kiểm tra các tính năng giới hạn tốc độ và nói rằng
giới hạn tốc độ chỉ hoạt động nếu cùng một PID được đưa ra
Tôi đoán đây là lý do tại sao nó không áp dụng ở đây.
Trên máy tính để bàn của tôi:
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
Trên máy chủ của tôi:
Jul 5 13:37:45 server postfix/smtpd[426]: NOQUEUE: reject_warning: RCPT from unknown[177.11.51.178]: 451 4.3.0 <some_adress@yahoo.com.br>: Temporary lookup failure; from=<address@gmail.com> to=<some_adress@yahoo.com.br> 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 <some_adress@yahoo.com.br>: Temporary lookup failure; from=<address@gmail.com> to=<some_adress@yahoo.com.br> 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 <some_adress@yahoo.com.br>: Temporary lookup failure; from=<address@gmail.com> to=<some_adress@yahoo.com.br> 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 <some_adress@yahoo.com.br>: Temporary lookup failure; from=<address@gmail.com> to=<some_adress@yahoo.com.br> proto=ESMTP helo=<mail.SERVER.TEST>
Vì vậy, tính năng giới hạn tốc độ của IIUC rsyslog không liên quan ở đây vì mỗi dòng nhật ký được viết bởi một quy trình khác nhau.
Chỉnh sửa 2: Hạn chế kích thước thư mục
Cuối cùng tôi đã giới hạn kích thước của /var/log
việc sử dụng một hệ thống tập tin ảo (như được đề xuất ở đây ).
Tôi có thể thiết lập một phân vùng riêng vào lần tới khi tôi cài đặt Linux.
Bây giờ tôi đang giữ câu hỏi này vì tôi coi đây là một cách giải quyết hơn là một câu trả lời.
100 * 200 * 12 * 60 * 24 = 345600000
=> khoảng 330 Mb mỗi ngày, nghe có vẻ chấp nhận được. Đáng ngạc nhiên, trong kern.log của tôi, tôi thấy hơn 5000 tin nhắn được đánh dấu thời gian với cùng một giây./etc/rsyslog.conf
chứa$ModLoad imuxsock
dòng, và không có gì vềSystemLogRateLimit
.