Как мне ограничить размер моего системного журнала?

У меня на компьютере моей мамы работает Ubuntu 12.04 LTS. Он работал просто отлично, но весь внезапный системный журнал заполнялся. И, заполняя, я имею в виду, что я только что удалил /var/log/syslogфайл размером 400 ГБ. Да - гигабайты

Хотя я уверен, что там была некоторая полезная информация, я не уверен, что 400 ГБ - это какая-либо информация, которую нужно просеять. И что на самом деле удивительно, так это то, что это произошло в течение 8 часов - я бегал dfоколо полудня, и между тем и сейчас ее драйв заполнил 30% (от чуть менее 70% до 100%).

Что может быть причиной этого и как я могу это исправить?

РЕДАКТИРОВАТЬ Похоже, USB является преступником:

Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157829] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157836] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157842] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157849] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157857] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157863] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157870] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157877] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157884] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157891] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use

Вы должны выяснить, что является причиной большого количества сообщений, как будто вы решаете эту проблему, а затем исправляете большой файл журнала.

Тем не менее, до тех пор вы можете положить в базу ротации бревен на одном из следующих.

• время (например, вращаться каждый день)
• размер (например, поворот, когда файл достигает 10 МБ)

Это уже будет установлено в системе по умолчанию: /etc/logrotate.d/rsyslog

 /var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
            reload rsyslog >/dev/null 2>&1 || true
    endscript
 }

Отсюда видно, что он будет ежедневно вращать файл / var / log / syslog и хранить 7 копий повернутого файла.

Вы можете изменить это, чтобы повернуть на ограничение размера, скажем, 1 МБ или уменьшить количество копий, которые он хранит.

Предупреждение: это не устранит основную причину вашей проблемы , однако выиграет вам некоторое время, так как остановит заполнение файловой системы.

• Источник: /etc/logrotate.d/rsyslog
• Источник: man logrotate

Ограничить размер logrotate

Откройте /etc/logrotate.d/syslogфайл конфигурации

sudo nano /etc/logrotate.d/syslog

Файл выглядит как что-то. нравиться

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
....
...

Добавьте, например, size 100k в скобках. После этого это должно выглядеть так:

/var/log/syslog
{
    rotate 7
    size 100k
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Обратите внимание, что это ограничивает размер вращающихся файлов, а не фактический файл системного журнала. Сохраните файл. При следующем запуске задания logrotate chron будет ограничен размер повернутых журналов.

Ограничить размер текущего системного журнала

Чтобы ограничить размер /var/log/syslog, вы должны отредактировать /etc/rsyslog.d/50-default.confи установить фиксированный размер журнала.

Добавьте или измените этот параметр, изменив следующую строку в /etc/rsyslog.d/50-default.conf:

.*;auth,authpriv.none       -/var/log/syslog

Вот выдержка из руководства rsyslog :

Выходные каналыопределяются через директиву $ outchannel. Его синтаксис следующий: $ outchannel name, имя-файла, max-size, action-on-max-size name - это имя выходного канала (не файла), file-name - это имя файла, в который нужно записать , max-size - максимально допустимый размер и action-on-max-size - команда, которая будет выдана при достижении максимального размера. Эта команда всегда имеет ровно один параметр. Двоичный файл - это та часть action-on-max-size перед первым пробелом, его параметр - все, что находится за этим пробелом. Обратите внимание, что максимальный размер запрашивается ДО записи сообщения журнала в файл. Поэтому обязательно установите этот предел достаточно низким, чтобы любое сообщение могло соответствовать. Для текущей версии полезно установить ее на 1 КБ ниже, чем вы ожидали. Максимальный размер всегда должен быть указан в байтах - специальных символов нет (например, 1k, 1m, …) На данном этапе развития. Имейте в виду, что $ outchannel просто определяет канал с именем. Это не активирует его. Для этого вы должны использовать селекторную линию (см. Ниже). Эта строка выбора включает имя канала плюс знак $ перед ним. Образец может быть:, : omfile: $ mychannel В своей текущей форме выходные каналы в основном предоставляют возможность ограничения размера выходного файла. Для этого укажите максимальный размер. Когда этот размер будет достигнут, rsyslogd выполнит команду action-on-max-size, а затем снова откроет файл и повторите попытку. Команда должна быть чем-то вроде скрипта ротации журналов или чего-то подобного.

Если нет команды action-on-max-size или команда не разрешила ситуацию, файл закрывается и никогда не открывается повторно rsyslogd (за исключением, разумеется, хуппинга). Эта логика была интегрирована, когда мы впервые столкнулись с серьезными проблемами с файлами размером более 2 ГБ, что могло привести к дамперному ядру rsyslogd. В таких случаях более целесообразно прекратить запись в один файл. Между тем, rsyslogd был исправлен для поддержки файлов размером более 2 ГБ, но, очевидно, только в файловых системах и версиях операционных систем, которые это делают. Так что все же имеет смысл применять ограничение размера файла 2 ГБ.

Здесь максимальный размер составляет 1 МБ, поместите эту строку перед *.*; ...строкой

$outchannel mysyslog,/var/log/syslog,1048576

и изменить *.*; ...строку в

*.*;auth,authpriv.none  :omfile:$mysyslog

Перезапустите rsyslogd

sudo service rsyslog restart

У меня была такая же проблема с Lexmark Pro915 в течение двух недель. Я сделал две вещи, и теперь он работает нормально. Я переустановил драйвер. (Не думайте, что это помогло.) Я вынул USB-расширение, которое имело общую длину почти 15 футов и которое могло быть не полностью совместимым. Я подозреваю, что драйвер Lexmark для систем Linux может обнаруживать плохой или плохо синхронизированный сигнал и хочет сообщать вам об этом 10 миллиардов раз в день. Попробуйте как-то улучшить свое соединение.

Logrotate и подобные решения не помогли мне. Kern.log и syslog вместе записывали более 1 ТБ в день! Logrotate может помочь, если вы сможете настроить его запуск каждые двенадцать минут.