У меня есть компьютер своей мамы под управлением 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
Необходимо узнать то, что вызывает большую сумму сообщений, как будто Вы устраняете эту проблему затем, Вы фиксируете большой файл журнала.
Однако до тех пор можно вставить основу вращения журнала на одном из ниже.
Это уже будет установкой в системе по умолчанию: /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 МБ или уменьшает, сколько копий он хранит.
Предупреждение: Это не зафиксирует первопричину Вашего выпуска , однако это купит Вас некоторое время, поскольку это будет мешать файловой системе заполниться.
У меня была та же проблема с Lexmark Pro915 в течение двух недель. Я сделал две вещи, и это теперь хорошо работает. Я переустановил драйвер. (Не думайте, что это было тем, что помогло.) Я вынул расширение USB, которое я использовал, который сделал общую длину почти 15' длинный и который, возможно, не был совершенно совместим. Я подозреваю, что драйвер Lexmark для систем Linux мог бы обнаруживать бедных, или плохо синхронизированный, сигнал и желать сказать Вам об этом 10 миллиардов раз в день. Попытайтесь улучшить свое соединение так или иначе.
Logrotate и аналогичные решения не помогли мне. Kern.log и системный журнал вместе регистрировали больше чем 1 ТБ в день! 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