Очень большие файлы журнала, что мне делать?
( Этот вопрос касается аналогичной проблемы, но он говорит о повернутом файле журнала.)
Сегодня я получил системное сообщение относительно очень низкого /var пространство.
Как обычно, я выполнил команды в строке sudo apt-get clean что немного улучшило сценарий. Затем я удалил повернутые файлы журнала, что опять же дало очень небольшое улучшение.
При осмотре я обнаружил, что некоторые файлы журнала в /var/log вырос, чтобы быть очень огромными. Чтобы быть конкретным, ls -lSh /var/log дает,
total 28G -rw-r----- 1 syslog adm 14G Aug 23 21:56 kern.log -rw-r----- 1 syslog adm 14G Aug 23 21:56 syslog -rw-rw-r-- 1 root utmp 390K Aug 23 21:47 wtmp -rw-r--r-- 1 root root 287K Aug 23 21:42 dpkg.log -rw-rw-r-- 1 root utmp 287K Aug 23 20:43 lastlog
Как мы видим, первые два являются оскорбительными. Я слегка удивлен, почему такие большие файлы не были повернуты.
И что же мне делать? Просто удалите эти файлы и затем перезагрузите компьютер? Или пойти на несколько более разумных шагов?
Я использую Ubuntu 14.04.
ОБНОВЛЕНИЕ 1
Начнем с того, что системе всего несколько месяцев. Мне пришлось установить систему с нуля пару месяцев назад после сбоя жесткого диска.
Теперь, как советовали в этом ответе, я сначала проверил файлы журналов с ошибками, используя tailНет ничего удивительного. Затем для более глубокой проверки я выполнил этот сценарий из того же ответа.
for log in /var/log/{syslog,kern.log}; do
echo "${log} :"
sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
| sort | uniq -c | sort -hr | head -10
done
Процесс занял несколько часов. Выход был в строке,
/var/log/syslog : 71209229 Rafid-Hamiz-Dell kernel: sda3: rw=1, want=7638104968240336200, limit=1681522688 53929977 Rafid-Hamiz-Dell kernel: attempt to access beyond end of device 17280298 Rafid-Hamiz-Dell kernel: attempt to access beyond end of device 1639 Rafid-Hamiz-Dell kernel: EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024) <snipped> /var/log/kern.log.1 : 71210257 Rafid-Hamiz-Dell kernel: attempt to access beyond end of device 71209212 Rafid-Hamiz-Dell kernel: sda3: rw=1, want=7638104968240336200, limit=1681522688 1639 Rafid-Hamiz-Dell kernel: EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)
(/dev/sda3 мой домашний каталог Как мы можем найти,
lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 122.1G 0 part / ├─sda2 8:2 0 7.6G 0 part [SWAP] └─sda3 8:3 0 801.8G 0 part /home
Почему процесс захочет писать за пределом, на самом деле выходит за рамки моего понимания. Возможно, я захочу задать другой вопрос на этом форуме, если это продолжится даже после обновления системы.)
Затем из этого ответа (вы можете проверить это для более глубокого понимания), я выполнил,
sudo su -
> kern.log
> syslog
Теперь эти файлы имеют нулевой размер. Система работает нормально до и после перезагрузки.
Я посмотрю эти файлы (вместе с другими) в ближайшие несколько дней и сообщу
они ведут себя необычно.
В качестве заключительного замечания, оба оскорбительных файла (kern.log а также syslog), повернуты, как проверка файлов (grep помог) внутри /etc/logrotate.d/ показывает.
ОБНОВЛЕНИЕ 2
Файлы журнала фактически вращаются. Похоже, большие размеры были достигнуты за один день.
4 ответа
Просто удалите эти файлы и затем перезагрузите компьютер?
Нет. Пустите их, но не используйте rm потому что это может привести к сбою чего-то в то время как вы печатаете touch Команда воссоздать его.
Кратчайший метод:
cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log
> kern.log
> syslog
exit
Если не root, то потребуется sudo, Взято из другого ответа на AU.
ДО ТОГО, ЧТО ВЫ ДЕЛАЕТЕ ЭТО. Сделать tail {logfile} и проверьте, есть ли причина для них быть такими большими. Если этой системе уже несколько лет, не должно быть никаких причин для этого, и решение проблемы лучше, чем позволить этому продолжаться.
И kern.log, и syslog обычно не должны быть такими большими. Но, как я уже сказал: если эта система запущена и работает годами и годами, это может быть нормально, и файлы просто необходимо очистить.
И чтобы это не стало таким большим в будущем logrotate, Это довольно просто и сжимает файл журнала, когда он становится больше, чем размер, установленный вами.
Еще одна вещь: если вы не хотите удалять содержимое, вы можете сжать файлы, скопировав или распаковав их. В результате вы получите файлы, вероятно, на 10% больше, чем сейчас. То есть, если на диске еще есть место для этого.
Вероятно, стоит попытаться установить, что заполняет журналы, - просто визуально изучив их, используя less или же tail команда
tail -n 100 /var/log/syslog
или если оскорбительные строки слишком глубоко скрыты, чтобы легко увидеть происходящее, что-то вроде
for log in /var/log/{dmesg,syslog,kern.log}; do
echo "${log} :"
sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
| sort | uniq -c | sort -hr | head -10
done
(примечание: при наличии таких больших файлов это может занять некоторое время), которое попытается удалить метки времени, а затем сосчитать наиболее часто встречающиеся сообщения.
Мой метод для очистки системных файлов журнала заключается в следующем. Шаги 1 и 2 являются необязательными, но иногда вам нужно проверить старые журналы, а резервное копирование иногда полезно.;-)
Необязательно: Скопируйте файл журнала
cp -av --backup=numbered file.log file.log.oldНеобязательно: используйте Gzip для копии журнала
gzip file.log.oldИспользуйте /dev/null для чистого файла
cat /dev/null > file.log
И мы используем для этого журналы (только на нескольких серверах) logrotate и еженедельно выполняем сценарием cron, который сжимает все файлы с *.1 (или следующим поворотом) с помощью gzip.
Я установил Ubuntu 16.04 сегодня и заметил ту же проблему. Тем не менее, я исправил это с busybox-syslogd. Ага! Я только что установил этот пакет, и проблема была решена.:)
$ sudo apt-get install busybox-syslogd
После установки этого пакета выполните сброс syslog а также kern.log:
sudo tee /var/log/syslog /var/log/kern.log </dev/null
Надеюсь, это простое решение пригодится окружающим.