Внезапно стало мало свободного места на диске? Возможно, проблема в логах.


Дата: 02 июня 2010





О чем это я?
Начинающиеся пользователи linux могут столкнуться с проблемой, когда на жестком диске начинается заканчиваться свободное место. Казалось бы ничего нового не устанавливали, а памяти с каждым днем все меньше и меньше до тех пор пока система совсем не откажется работать.
Данная статья поможет новичкам разобраться с проблемой быстро и без паники.

Да, проблема есть! В какую сторону копать?
При такой проблеме стоит первым делом подозревать систему записи логов (системных журналов, сообщений об ошибках системы). Логи - это системные записи от различных программ и служб работающих в системе. При нормальных условиях эти логи занимают сравнительно мало места на диске, но если в какой-то программе (как это было с network manager) есть баг из-за которого пишутся логи или что-то иное работает не так, то логи могут начинать писаться со слишком частой регулярностью.
На моем опыте (с pptp в nm) логи росли со скоростью около 1Гб в неделю. Это практически для любого пользователя будет проблемой.

Диагностика
Чтобы убедиться, что виноваты именно логи нужно заглянуть в каталог /var/log через файловый менеджер или команду оценки размера каталога du.
Если размеры этой папки больше 100Мб, то проблема наверняка в них.

Лечение
Теперь когда мы поняли, что проблема в логах нужно решить эту проблему.
Конечно можно просмотреть логи и найти первопричину проблемы и исправить её, но это под силу не каждому профи.
Для новичка будет удобнее просто отключить систему записи логов.
Отключение rsyslog
Для ведения журналов, скорее всего, используется служба rsyslog.
Для ее отключения введите команду от суперпользователя:
/etc/init.d/rsyslog stop
Тем не менее некоторые программы могут работать некорректно при отключенной службе или записывать логи напрямую, но это скорее исключение, чем правило.
Более мощное лечение - перенос логов во временную память
Если предыдущий метод не помог, то можно приравнять папку логов к tmpfs (временная память).
Для этого отредактируем конфигурационный файл /etc/fstab.
Выполняем от суперпользователя:
nano /etc/fstab
*Вместо nano можно ввести gedit (GNOME) или kate (KDE).
В добавляем строки:
tmpfs /var/log/apt tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0


Сохраняем файл, перезагружаемся.

Смотреть также:
Ротация логов с помощью logrotate

Комментарии:
Автор: Дядя Вася,   дата: 02 июня 2010   02:17:52
Отвратительная статья, напоминающая потуги одного известного шахтёра на центральном канале рассказывать людям о лечении болезней.

По пунктам:
1) В нормальной системе логи программ ротируются с помощью logrotate, которая удаляет логи старше определённого возраста. В итоге логи в нормальных ситуациях не растут дальше определённого размера.

2) Отключить сислог значит лишить систему возможности сообщать о критических проблемах. Решение с tmpfs не такое резкое, но не менее глупое: логи после ребута теряются, а память (оперативная) засирается.

В итоге вместо демонстрации знания tmpfs автору следовало бы показать как поставить logrotate и рассказать про anacron.
Автор: Дядя Вася,   дата: 02 июня 2010   02:18:13
Дальше уже просто про безграмотность:

Автор предлагает остановить rsyslog. Даже если закрыть глаза на то, что в конкретном дистре может быть другая реализация сислога (на вскидку их не менее четырёх), возникает вопрос: останавливать его теперь надо будет после каждой загрузки? Почему не рассказать как полностью запретить запуск демона (хотя бы и на примере любимого дистра автора).

И ещё. Я понимаю, что статья для новичков, но всё же никто не называет место на жёстком диске памятью, даже если с точки зрения теории это верно. Памятью называют оперативную память, а на жёстком диске -- там "место".
Автор: Subsanek,   дата: 02 июня 2010   07:01:52
>В нормальной системе логи программ ротируются с помощью logrotate

Но у нас ненормальная ситуация. В таких случаях обычно быстрее заполняется всё место, чем удаляются старые логи.


>Отключить сислог значит лишить систему возможности сообщать о критических проблемах.

Если есть подозрения на критические проблемы, то можно и снова включить.


>автору следовало бы показать как поставить logrotate

Ну будет быстрая ротация, но сколько памяти то писаться будет (по сотни мегабайт в день) что очень не благоприятно скажется на производительности.


>Почему не рассказать как полностью запретить запуск демона (хотя бы и на примере любимого дистра автора).

Зайти /etc/init.d и лишить право на запуск rsyslog либо другой демон, в зависимости от дистрибутива.
chmod -x /etc/init.d/rsyslog
Опытные пользователи могут отредактировать конфиг системы логирования (тот-же rsyslog.conf).
Автор: Просто юзер, мимо проходил,   дата: 02 июня 2010   07:49:20
Вот как обычному человеку, мне кажется, что вы игнорируете причину и лечите следствие. Как вы же сами выше сказали, если логи быстро растут, значит что-то работает не так. ТАК ПОЧЕМУ бы нам не починить то, что не так работает?
Автор: vadim303,   дата: 02 июня 2010   09:46:33
Полностью солидарен с предыдущими ораторами :) Бесполезная, или даже скорее вредная статья...
И кстати logrotate не только удаляет старые логи, но также способен ограничивать размер этих логов и количество ротаций, а также пересылку их с последующим удалением... ну и действительно, для начала неплохо было бы разобраться кто и почему так засирает логи :)

Да, и вместо аморфного linux было бы неплохо писать дистрибутив. Ведь не только сами демоны могут быть разными, но и методы их остановки-запуска: системы инициализации тоже различаются :)
Автор: Subsanek,   дата: 02 июня 2010   11:15:55
>ТАК ПОЧЕМУ бы нам не починить то, что не так работает?

Это конечно более хорошая идея, но как уже писалось в статье, новички не смогут разобрать логи и возможно они пишуться из-за бага. В Networkmanager по сей день этот баг присуствует и вылечить его можно только написание патча вручную (новичку предлогать?) или использованием вообще другого менеджера.


>И кстати logrotate...
Заинтересовали, в ближайшее время поизучаю logroate и напишу еще статью если это будет действительно хорошим инструментом.
Но тем не менее при записи сотен строк в секунду проблема будет еще с производительностью системы в целом, а это бональным инструментом очистки не решить!
Автор: yuri,   дата: 02 июня 2010   14:24:26
Автору большой плюс за то, что не стирает комментарии. Новички смогут ознакомиться и с другими решениями, озвученными в коментах.

А убрать из "автозагрузки" сервис путем убирания бита выполняемости - это круто...
Никогда так не делайте, ищите способы, характерные для дистриба. chkconfig для RH-based, rc-update для gentoo и т.д.

Во-первых при обновлении этого скрипта его права восстановятся (а пользователь не заметит и служба начнет выполнятся снова).

Во-вторых, если за машину сядет более опытный пользователь - ему придется разбираться, почему же сервис не запускается штатными средствами.
Автор: Subsanek,   дата: 02 июня 2010   19:11:33
>другими решениями

Решений много.
Некоторые даже пишут скрипт копирования всех логов в /dev/null =)
Автор: Дядя Вася,   дата: 03 июня 2010   15:29:41
Дядя Федя, говорят, в свежих версиях coreutils удаление "/" уже так просто не прокатывает ;-)
Автор: Дядя Вася,   дата: 03 июня 2010   15:32:21
Subsanek, обычно когда происходит критическая проблема, её причину и ищут в логах, постфактум. Постфактум тут ключевое слово.

Ну и в нормальном дистре просто нереально иметь такую проблему с NM. Либо ты юзаешь какой-то bleeding edge, и тогда незачем рядиться в шкуру "обычного пользователя", либо у тебя просто не бывает такой проблемы.

А то, что не удаляешь комментарии -- действительно молодец.
Автор: Subsanek,   дата: 03 июня 2010   15:44:38
>Либо ты юзаешь какой-то bleeding edge

Debian


>А то, что не удаляешь комментарии -- действительно молодец.

Зачем их удалять-то ?
Автор: galaxyman,   дата: 03 июня 2010   16:58:10
по моему есть где то в конфиге опция - детализации логов, я уже сталкивался с такой проблемой
если уменьшить детализацию (подробность) логов, то сервис отключать не нужно
Автор: Дядя Петя,   дата: 14 января 2011   17:02:44
Спасибо за статью и обсуждения. Здесь как раз достаточно информации для того чтобы разобраться с логами. У меня кстати вопрос стоит более остро - 1 Гб за час. Спасмит библиотечка alsa_sync.c.
Автор: Monte,   дата: 18 марта 2014   12:38:08
Столкнулся с такой же проблемой.
Из споров понятно что нужно найти логи которыен растут из них определить причину... Хотя бы увидеть про што хоть логи... А уж потом лечить... И ни как не могу найти папку размер которой растет... какой Вариант поиска предложили бы Специ????
Заранее благодарен
Автор: Subsanek,   дата: 03 апреля 2014   16:53:40
Monte, найти папки большого размера можно попробовать через анализатор Baobab (на нашем сайте есть о нём статья).




 
Добавить комментарий:
Имя: *
e-mail:
Комментарий: *
Введите число 95: *


Архив статей:
Май 2017
Март 2017
Апрель 2016
Март 2016
Октябрь 2013
Сентябрь 2013
Май 2013
Март 2013
Ноябрь 2012
Июль 2012
Июнь 2012
Апрель 2012
Март 2012
Февраль 2012
Апрель 2011
Март 2011
Февраль 2011
Январь 2011
Декабрь 2010
Ноябрь 2010
Октябрь 2010
Сентябрь 2010
Август 2010
Июль 2010
Июнь 2010
Май 2010
Апрель 2010
Март 2010

Случайные:
Cairo-dock - функциональный док для Linux

Быстрая установка и настройка XAMPP

Смена менеджера дисплеев (DM) по-умолчанию (KDM,GDM и т.п)

Фонд свободного программного обеспечения и копилефт.

Что делать, если вы забыли свой пароль к linux

Виджеты в GNOME





Коллеги:    все
 Linux для всех

Наши баннеры:
linuxnow.ru
linuxnow.ru
Установить баннер