Очень большие файлы журнала, что мне делать?

( Этот вопрос касается аналогичной проблемы, но он говорит о повернутом файле журнала.)

Сегодня я получил системное сообщение относительно очень низкого /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

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

Просто удалите эти файлы и затем перезагрузите компьютер?

Нет. Очистите их, но не используйте, rmпотому что это может привести к сбою чего-либо, пока вы набираете touchкоманду для ее воссоздания.

Кратчайший метод:

cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

Если не рут это потребует 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 являются необязательными, но иногда вам нужно проверить старые журналы, а резервное копирование иногда полезно. ;-)

1. Необязательно: Скопируйте файл журнала

   cp -av --backup=numbered file.log file.log.old
   

2. Необязательно: используйте Gzip на копии журнала

   gzip file.log.old
   

3. Используйте / 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

Надеюсь, это простое решение пригодится окружающим.