Чи є правильний спосіб очищення журналів?

Мені було цікаво, чи існує правильний спосіб очищення журналів взагалі?

Я новачок у Ubuntu і намагаюся налаштувати Postfix. Журнал, про який йде мова, є /var/log/mail.log. Мені було цікаво, чи є правильний спосіб його очищення, а не я заходжу в нього і видаляю всі рядки і зберігаю його. Я вважаю, що іноді помилки не пишуться в неї відразу після того, як я очищую журнал і зберігаю його.

Бічна примітка: У мене виникають проблеми з налаштуванням Postfix і я намагаюся полегшити мені читання журналів, сподіваючись, що це може допомогти мені, а не прокручувати всю дорогу вниз.

Ви можете використовувати:

> /var/log/mail.log

Це вріже журнал, не редагуючи файл. Це також надійний спосіб повернути простір. Іноді люди роблять помилку, використовуючи rm у журналі, а потім відтворюють ім'я файлу, якщо інший процес відкриває файл, то ви не отримаєте простір, поки цей процес не закриє його обробкою, і ви можете зіпсувати його дозволи.

Також якщо ви переглядаєте вміст журналу, можливо, ви хочете скористатися tailкомандою:

tail -f /var/log/mail.log

Ctrl-C відірве хвостик.

Так, є правильний спосіб: ви зовсім не очищаєте журнали. Ви обертаєте їх. Обертання включає перемикання виходу журналу в новий файл під тим самим ім'ям, при цьому попередні N файлів журналу зберігаються під набором N пов'язаних імен файлів.

Те, як обертаються журнали, залежить від того, як їх записувати в першу чергу. Це часто недооцінений момент. Деякі відповіді тут торкаються принаймні, згадуючи, що деякі програми реєстрації зберігають відкритий дескриптор файлу журналу, тому просто видалення файлу не звільнить простір, а то й навіть переключить вихід на новий файл журналу.

Наприклад, якщо програма, що записує файл журналу, виходить multilogіз daemontoolsпакета , тоді ви взагалі нічого не робите для повороту журналів - жодних сценаріїв вручну, жодних cronзавдань. Просто скажіть, multilogщо вихід журналу - це каталог, і він сам підтримуватиме автоматично повернутий і обмежений розмір набір файлів N журналів у цьому каталозі.

Якщо програма, що записує файли журналів, йде svlogdз runitпакету , для іншого прикладу, то багато іншого стосується і того ж. Ви нічого не робите, окрім того, як навести інструмент на каталог. Він сам буде підтримувати автоматично повернутий і обмежений розмір набір N файлів журналів у цьому каталозі.

Якщо ви використовуєте rsyslogдля запису файлів журналів, програму реєстрації можна сказати припинити після того, як файл журналу досягне певного розміру та запустить сценарій . Ви повинні написати м'ясо сценарію, щоб фактично перейменувати файл журналу та видалити старі файли журналів на основі обмежень загального розміру, але принаймні програма реєстрації закрила файл і призупинила запис журналу, поки це відбувається.

Старий syslogdспосіб повороту журналів, який все ще очікується при реєстрації таких програм, як syslog-ng та як приклади таких інструментів, про які logrotateйдеться djangofanв іншій відповіді тут, є дещо більш небезпечним. Один запускає cronзавдання, яке періодично перейменовує файли журналів, і перезапускає демон-журнал (використовуючи будь-який керівник демона, під яким він працює). Проблема з цим, звичайно, полягає в тому, що він не застосовує обмеження загального розміру. На повільних тижнях можна отримати N дуже малих щоденних файлів журналу, тоді як у напружені дні можна отримати 1 дуже великий файл журналу, що значно перевищує обмеження розміру.

Тому пізніше і більш досконалі інструменти , як multilogі svlogdмають параметри конфігурації розмір файлу і на самому ділі перевірити файл журналу розміри себе, звичайно. Світ дізнався, що опитування журналів за графіком із cronзавданнями або навіть logrotateдемон, залишає вікна, щоб розмір був невірним, і що належне місце для цих перевірок, і настільки жорстко застосовувати обмежені розміри, визначені адміністратором, щоб Файли журналу ніколи не ковтають розділ, на якому вони перебувають, - це програма, яка насправді виписує файли в першу чергу.

Ви також можете використовувати це ..

truncate /opt/package/logs/*.log --size 0

Тут усі файли журналу в / opt / package / logs стануть порожніми ..

Так, є інструмент для Linux під назвою LogRotate .

Якщо ви очищаєте журнал, це звільнення місця, ви можете передати їм / dev / null, не перериваючи запис програм у нього. Ніколи не видаляйте їх! деяке програмне забезпечення може скаржитися, припинивши роботу або повністю ігноруючи журнал до наступного перезавантаження

cat /dev/null > /path/to/logfile

# to empty all the logs in a directory
for i in /var/log/*; do cat /dev/null > $i; done

Перезапис короткого та сумісного вмісту: : > /dest/file

Але також є багатократний (2) системний виклик та відповідний інструмент простору користувачів truncateна багатьох * NIX'е.

Якщо ви хочете зберегти файл перед його очищенням, ви можете зробити:

cp /var/log/mail.log /var/log/mail.log.1 && echo -n "" > /var/log/mail.log

Якщо ви хочете шукати певний текст або електронну пошту в журналі, ви можете скористатися grep. Якщо ви хочете зберегти графіку щодо використання пошти, ви можете використовувати AWStats.

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

# Clear nginx logs.
# @usage delnginxlogs
function delnginxlogs() {
  echo "--------------- ⏲  Clearing logs... ---------------"

  # Clear logs.
  for i in /var/log/nginx/*; do cat /dev/null > $i; done

  echo "--------------- ⏲  Deleting .gz log files... ---------------"

  # Delete .gz files.
  find /var/log/nginx -type f -regex ".*\.gz$" -delete

  echo "--------------- 💯 DONE: NGINX logs cleared ... ---------------"
}

cat / dev / null> / шлях / до / logfile

Працює для мене