LINUX.ORG.RU

CentOS - логи забивают место

 , ,


0

1

Здравствуйте. Имеется установленная CentOS с MySQL, PHP+Apache. Сервак только поставили и не прошло еще и 3 недель (стоит без эксплуатации, просто тупо включен и все, ничто на нем не выполняется). Тестировали и внезапно отвалился мускл и перестал запускаться.

df показал:

Filesystem                       1K-blocks     Used Available Use% Mounted on
/dev/mapper/xxx_root              51606140  5106140         0 100% /
tmpfs                              4028620        0   4028620   0% /dev/shm
/dev/cciss/c0d0p1                   495844    69993    400251  15% /boot
/dev/mapper/xxx_home             645277736   201968 612297528   1% /home

Понятно, мускл перестал работать из-за free space'a . Причина нехватки места: логи в var/log забили все место. Были логи, которые весили больше 20Гб. messages-201404хх - 17Gb, lbtv.log - 110Mb и т.д.

С Linux практически не сталкивался, но здесь просто необходимо это сделать. Вопрос: Как решить эту проблему с забиванием места логами (за 2-3 недели съели все место)? Спасибо.



Последнее исправление: Prime (всего исправлений: 1)
Ответ на: комментарий от science

В добавок к настройкам logrotate таки стоит заглянуть в логи, чтобы узнать, от чего они разрастаются

anonymous
()

Во-первых, нужно ли тебе содержимое тех логов?

dvrts ★★★
()
Apr  6 03:43:16 xxx-srv kernel: psmouse.c: bad data from KBC - timeout
Apr  6 03:43:16 xxx-srv kernel: psmouse.c: bad data from KBC - timeout
Apr  6 03:43:16 xxx-srv kernel: psmouse.c: bad data from KBC - timeout
Apr  6 03:43:16 xxx-srv kernel: psmouse.c: bad data from KBC - timeout
Apr  6 03:43:16 xxx-srv kernel: psmouse.c: bad data from KBC - timeout
Apr  6 03:43:16 xxx-srv kernel: psmouse.c: bad data from KBC - timeout

вот 10Gb Лог файл содержит такую информацию. В секунду записывает около 550 строк с этим содержимым. P.S.мыша и клава из консольки в сервак воткунты, дистрибутив без графической оболочик. Клава работает (иначе нчиего там сделать не мог бы) Считаю что данное содержимое не очень критично, чтобы его хранить в 50 Гб )

Prime
() автор топика
Ответ на: комментарий от Prime

Ну и скопируй это сообщение в гугль

anonymous
()
Ответ на: комментарий от Prime

Проще всего будет вытащить мышь из сервера.

ValdikSS ★★★★★
()
Ответ на: комментарий от Prime

Сделай

echo 1 > /путь/к/лог/файлу

Это уменьшит размер этого файла до минимума, тем самым освободит место.

Потом кури маны по logrotate и желательно вынести /var/log на отдельную партицию

dvrts ★★★
()
Ответ на: комментарий от rogerw

Тебе не приходит в голову что если бы логи не были нужны, их бы просто не было?

dvrts ★★★
()
Ответ на: комментарий от yars068

Да работает у него ротация. В CentOS по умолчанию настроено.

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

TEX ★★★
()
Ответ на: комментарий от TEX

Просто не все логи ротацию проходят, видимо. В слаке оно тоже по умолчанию настроено, но только на то, что идет в дистрибутиве. А с дополнительным ПО, если майнтайнер пакета не озаботился, то нужно это делать самому. Я тоже когда-то был ССЗБ :)

yars068 ★★★★
()
Ответ на: комментарий от yars068

Ну и да, само собой, настройки разные бывают. Одни логи раз в сутки нужно просто пересоздавать, другие надо урезать, сжимать и т.д.

yars068 ★★★★
()
Ответ на: комментарий от yars068

Просто не все логи ротацию проходят, видимо.

Вот этот messages-201404хх - 17Gb ротируется стопудово,ибо

$ cat /etc/logrotate.d/syslog
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}
TEX ★★★
()
Ответ на: комментарий от TEX

Мда. У меня такого никогда не было. Было, что _все_ логи совокупно занимали место - под корень отдано 10 гигов, еще 10 - под /usr. Разок получил переполнение корня, разобрался с ротацией и теперь УМВР, логи больше 100 Мбайт не занимают. Но то десктоп, на сервере, конечно, лучше побольше сохранять.

yars068 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.