Как я могу освободить место из массивной папки 39.5GB / var / log /?

Вы должны посмотреть журналы и посмотреть, что им пишется. Я предполагаю, что ufw / iptables (вы регистрируете весь сетевой трафик).

ufw - когда вы регистрируете все пакеты, вы получаете большие журналы. Если вы не собираетесь просматривать журналы, отключите регистрацию. Если вы хотите контролировать свою сеть, используйте snort. Snort отфильтрует тысячи полученных вами пакетов и предупредит вас о потенциально проблемном трафике.

Полагаю, виновником является ufw, и вы получаете большой журнал в kern.log, потому что вы также регистрируете пакеты там.

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

Если вы не можете решить проблему, вы можете настроить системный журнал так, чтобы он не заполнял ваши журналы.

См. http://manpages.ubuntu.com/manpages/precise/man5/syslog.conf.5.html

. Если вы предоставите более подробную информацию о проблеме, мы можем помочь лучше отладить.

Вы не должны удалять всю папку , но вы можете удалять файлы журналов «Old-Packed» без ущерба для вашей системы.

Для обычного домашнего пользователя безопасно удалить любой файл журнала, который сжат и имеет расширение .gz (как вы можете видеть на рисунке).

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

Удаление /var/log, вероятно, плохая идея, но удаление отдельных лог-файлов должно быть в порядке.

На моем ноутбуке с небольшим SSD-диском я установил /var/log (и /tmp и /var/tmp) в качестве точек монтирования tmpfs, добавив следующие строки в /etc/fstab:

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

Единственная проблема, с которой я столкнулся, заключается в том, что некоторые программы (особенно APT) хотят записывать свои журналы в подкаталоги /var/log и недостаточно умны, чтобы создавать эти каталоги, если они не существуют. Добавление строки mkdir /var/log/apt в /etc/rc.local решило эту конкретную проблему для меня; в зависимости от того, какое программное обеспечение вы установили, вам может понадобиться создать и другие каталоги.

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

Я бы не удалил всю папку / var / log - это сломает вещи.

Вы можете просто уничтожить журналы, как подсказывает @jrg, но если только перезаписываются вещи, записывающие в файлы журналов (в основном, syslogd), которые фактически не вернут вам место на диске, так как файлы будут продолжать существовать в удаленных состояние, пока файловые дескрипторы не будут закрыты.

Лучше было бы выяснить, почему журналы не вращаются (а затем удаляются). logrotate должен сделать это для вас, и я подозреваю, что он не запускается каждую ночь, как следует.

Первое, что я хотел бы сделать, было бы:

sudo /etc/cron.daily/logrotate

Это должно вращать файлы журналов (поэтому kern.log становится kern.log.1); и затем вы можете удалить kern.log.1 и т. д., чтобы освободить место на диске.

Если все хорошо, то следующий вопрос - почему это не происходит автоматически. Если вы выключаете компьютер ночью, убедитесь, что у вас установлен anacron .

У меня было несколько ГБ / var / log , которые я сжал до менее 250 МБ, используя как journald.conf , так и logrotate :

config для journald: (cf man journald.conf)

    SystemMaxUse=250M
    SystemMaxFileSize=50M

конфигурация для logrotate:

  compress

  /var/log/journal {
    daily
    dateext
    delaycompress
    copytruncate
    notifempty
    missingok
    rotate 3
    size 500k
    sharedscripts
  }

У меня была проблема с огромными файлами журналов (около 100 ГБ каждый) с некоторыми бесполезными сообщениями от gnome «не удается найти видеобуфер» или что-то в этом роде. Выполнение:

sudo rm -rf /var/log/user.log sudo rm -rf /var/log/syslog sudo rm -rf /var/журнал/сообщения

не решил проблему, но сделал systemctl перезапустить syslog.service сразу после освобождения места, используемого этими файлами.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я не эксперт в этом, используйте на свой страх и риск!

Обнаружив, что моя папка /var/log/journal занимает несколько ГБ, я сделал следующее:

https://ma.ttias.be/clear-systemd-journal/

journalctl --vacuum-time=10d

который очистил 90%+ от него