Мне было интересно, есть ли вообще правильный способ очистки журналов?
Я новичок в 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
Но есть также системный вызов 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> / путь / к / файлу журнала
Работает для меня