Удалить все / var / log?

Вместо того, чтобы удалять файлы, вы должны их повернуть, например. грамм. с помощью logrotate.

Вы никогда не знаете, когда вам действительно понадобятся журналы, сделанные некоторое время назад, поэтому лучше заархивировать их (до разумного возраста, например, 3 месяцев).

logrotate может сжимать ваши старые файлы журналов, чтобы они не занимали много места на диске.

Удалить все файлы:

find /var/log -type f -delete

Удалить все .gz и повернутый файл

find /var/log -type f -regex ".*\.gz$"
find /var/log -type f -regex ".*\.[0-9]$"

Попробуйте запустить команду без "-delete", чтобы проверить ее.

Если вы удалите все в / var / log, вы, скорее всего, получите массу сообщений об ошибках за очень короткое время, поскольку там есть папки, которые, как ожидается, существуют (например, exim4, apache2, apt, cups, mysql, samba и больше). Плюс: есть некоторые службы или приложения, которые не будут создавать свои файлы журналов, если они не существуют. Они ожидают наличия хотя бы пустого файла. Итак, прямой ответ на ваш вопрос на самом деле "Не делай этого!!!".

Как указал дзёши, для этого нет причин. У меня работают серверы Debian, на которых не было удалено ни одного файла журнала за многие годы.

Я клонирую виртуальные машины от мастера. Имеет смысл очистить журнал на главном сервере, чтобы при загрузке клонов вы не получили журнал мастера. Я сделал в tcsh:

cd /var/log
foreach ii ( `find . -type f` )
foreach? cp /dev/null $ii
foreach? end

который очищает журналы, но сохраняет файлы.

Очистка всех журналов в системе Linux без удаления файлы:

for CLEAN in $(find /var/log/ -type f)
do
    cp /dev/null  $CLEAN
done

Самба (/var/www/samba) создает имена файлов журнала с IP-адресами, вы можете удалить их:

for CLEAN in $(find /var/log/samba -type f)
do
    rm -rf $CLEAN
done

Вы можете использовать опцию ctime для поиска старых файлов ... например:

find -ctime +30

Как объясняет bindbn, сначала попробуйте найти файлы выборки, а затем используйте опцию delete: D

/var/log часто имеет разрешения drwxrwxr-x, поэтому пользователь не имеет права записи, если пользователь не является пользователем root или не принадлежит к привилегированной группе. Это означает, что новые файлы журнала не могут быть созданы непривилегированными пользователями.

Приложения, которые ожидают входа в точку в /var/log часто сопоставляет файл с существованием где-то в /var/log иерархия во время установки (что часто происходит с повышенными привилегиями) и будет chmod и возможно chown это в то время для разрешений, подходящих для непривилегированных пользователей, которые будут использовать приложение.

Журналы Apache, например, обычно записываются nobody, который является пользователем с минимальным количеством привилегий, чтобы Apache мог выполнять свою работу, не подвергая систему чрезмерному риску. Но даже более обычное приложение часто ожидает возможности записи в файл журнала в /var/log.

Итак, что произойдет, если файл журнала и путь к нему не существуют? Это полностью зависит от приложения. Некоторые приложения незаметно пропускают ведение журнала. Остальные создадут множество предупреждений. А другие просто выручают. Нет жесткого правила; это зависит от бдительности разработчика приложения, а также от того, насколько важным разработчик считает свою способность вести журнал. В лучшем случае приложение попытается либо записать, либо, возможно, создать и затем записать в файл журнала в месте назначения в пределах /var/log, и окажется, что не может этого сделать, потому что он запускается пользователем, у которого нет прав для записи в эту часть файловой системы.

Короткий ответ - нет, не удаляйте все в /var/log - он нарушает условия контракта пользователей с достаточными привилегиями, чтобы делать такие вещи с приложениями, работающими в их системе, и вызывает некоторый шум, некоторый тихий сбой при регистрации и некоторый полный отказ.

Необходимое действие - настроить logrotate с соответствующими файлами конфигурации. Обычно ротация связана с заданием cron. Вращение может быть основано на интервале, на размере или на обоих. Можно даже настроить правила, которые избегают ротации на основе интервала, если файл журнала все еще пуст, когда интервал истекает. Ротация может включать отправку файлов журнала по почте, сжатие, удаление, измельчение и так далее.

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

Я реализовал здесь простой очиститель:

https://github.com/Lin-Buo-Ren/Coward-Unix-Log-Cleaner

Это просто:

• Удаляет имена файлов со следующими шаблонами лог-ротации имен файлов в /var/log
  • ^.*/.+\.[[:digit:]]+(\.[[:alpha:]]+)?$
  • ^.*/.+\.old$ (без учета регистра)
• Обрезать / очистить файлы с именами файлов со следующими шаблонами файлов журналов в /var/log
  • ^.*/.+\.log$ (без учета регистра)

function goodbyelogs {
find /var/log -type f
}

for i in return $(goodbyelogs);
do sudo cat /dev/null > $i;
echo "Log $i has been cleared";
done

создайте исполняемый скрипт и попробуйте запустить его как root, если sudo у вас не работает