Дуже великі файли журналів, що мені робити?

( Це питання стосується аналогічного питання, але воно говорить про повернутий файл журналу.)

Сьогодні я отримав системне повідомлення про дуже мало /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. Взято від іншого відповіді на АС.

ПЕРЕД ВАМ ТИ РОБИТИ. Зробіть atail {logfile} і перевірте, чи є причина, щоб вони були такими великими. Якщо цій системі вже кілька років, для цього не повинно бути причин, і вирішити проблему краще, ніж відпускати цю проблему.

І kern.log, і syslog зазвичай не повинні бути такими великими. Але як я вже сказав: якщо ця система працює і працює роками і роками, це може бути нормальним, і файли просто потрібно очистити.

І щоб у майбутньому це не стало таким великим: налаштування logrotate. Він досить простий і буде стискати файл журналу, коли він стає більшим за розмір, який ви встановили.

Ще одна річ: якщо ви не хочете видаляти вміст, ви можете стискати файли, розміщуючи їх або gzipping. Це призведе до того, що ви отримаєте файли, ймовірно, 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
   

І ми використовуємо для цього журнали (лише на декількох серверах) логротируем та щотижнево виконуємо за допомогою cron script, який усі файли з * .1 (або наступним поворотом) стискає gzip.

Я встановив Ubuntu 16.04 сьогодні, і я помітив ту саму проблему. Однак я виправив це за допомогою зайнятої-syslogd. Так! Я тільки що встановив цей пакет і проблема була вирішена. :)

$ sudo apt-get install busybox-syslogd

Після встановлення цього пакета скиньте syslogі kern.log:

sudo tee /var/log/syslog /var/log/kern.log </dev/null

Я сподіваюся, що це просте рішення буде корисним для інших людей навколо.