Есть ли правильный способ очистки журналов?

Мне было интересно, если есть правильный способ очистки журналов в целом?

Я новичок в 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 .

Если причина, по которой вы очищаете журнал, состоит в том, чтобы освободить место, вы можете использовать команду cat / 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

Но есть также системный вызов truncate (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> / path / to / logfile

Работает для меня