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

У меня есть компьютер своей мамы под управлением Ubuntu 12.04 LTS. Это работало просто великолепно, но весь внезапный системный журнал заполнялся. И путем заполнения я подразумеваю, что просто удалил a /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
13
задан 8 September 2012 в 20:23

3 ответа

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

Однако до тех пор можно вставить основу вращения журнала на одном из ниже.

  • время (например, вращаются каждый день)
  • размер (например, вращаются, когда файл достигает 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
  • : человек logrotate
12
ответ дан 21 October 2019 в 10:49

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

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

0
ответ дан 21 October 2019 в 10:49

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

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

sudo nano /etc/logrotate.d/syslog

Файл смотрит sth. как

/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, имя файла, макс. размер, action-on-max-size имя являются названием канала вывода (не файл), имя файла является именем файла, которое будет записано в, макс. размер максимальный позволенный размер и action-on-max-size команда, которая будет выпущена, когда макс. размер достигнут. Эта команда всегда имеет точно один параметр. Двоичный файл - то, что часть action-on-max-size перед первым пространством, его параметр - все позади того пространства. Обратите внимание на то, что макс. размер запрашивается ПРЕЖДЕ, ЧЕМ записать сообщение журнала в файл. Так обязательно установите этот предел довольно низко так, чтобы любое сообщение могло бы соответствовать. Для текущего выпуска устанавливая его 1k ниже, чем Вы ожидал, полезно. Макс. размер должен всегда указываться в байтах - нет никаких специальных символов (как 1k, 1 м, …) в этой точке разработки. Следует иметь в виду, что $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
6
ответ дан 23 November 2019 в 03:19

Другие вопросы по тегам:

Похожие вопросы: