Как остановить /var/log/kern.log.1 от потребления всего моего дискового пространства?

У меня есть жесткий диск емкостью 80 ГБ без каких-либо разделов. Однажды я понял, что потерял большую часть свободного места на диске. Я обнаружил, что /var/log/kern.log.1 занимает 25 ГБ места, и для этого файла нет опции удаления.

Вот скриншот проблемы:

Я новичок в Ubuntu / Linux. Пожалуйста помоги. Спасибо.

1
задан 24 May 2018 в 12:54

3 ответа

kern.log.1 является лишь одним из многих файлов журнала ядра.

Вместе они и группа messages.log.x могут занимать много Gb. Остальные файлы журналов в каталоге занимают около 1% от общей суммы, поэтому нет необходимости пытаться массово стереть каталог журнала. Это может быть даже вредно для вашей системы ..

Чтобы восстановить 99%, вот две команды, которые сделают трюк, удалив ненужные файлы с несколькими ГБ:

sudo rm /var/log/kern* &>/dev/null
sudo rm /var/log/messages* &>/dev/null

Эти файлы будут созданы снова в первый раз, когда они понадобятся.

Чтобы ответить на ваш вопрос конкретно: вы можете настроить задание cron, чтобы удалить их каждую полночь или раз в неделю, в зависимости от того, что было. [!d6 ]

Я использую их плюс

rm -rf ~/.cache/chromium/Default/Cache/* &>/dev/null

для моей полночной rsync резервной копии с основного / dev / sda SSD на жесткий диск с большим / dev / sdb. Это экономит место, и они не нужны ни в каком сценарии восстановления.

1
ответ дан 25 May 2018 в 02:35
  • 1
    Неверно, что это поведение встроено в Linux. Ядро Linux просто записывает эти сообщения журнала во внутренние (в памяти) буферы для доступа к приложениям пользовательского пространства. Это какой-то демон syslog, который затем вытаскивает эти журналы и записывает их в / var / log. Этот демон очень хорошо настраивается или даже полностью отключается. – Dreamer 6 November 2017 в 12:56
  • 2
    Хорошо. Существует много сообщений журнала, которые необходимы для продвинутых разработчиков, поэтому я не предлагаю полностью отключить его. Я запускаю ночную резервную копию rsync с SSD / dev / sda на большой / dev / sdb HDD, и для того, чтобы наилучшим образом использовать пространство, я делаю это выше, а также rm -rf /home/pi/.cache/chromium/Default/Cache/* &>/dev/null, поскольку ни один из них необходимы в сценарии восстановления. – SDsolar 8 November 2017 в 04:01
  • 3
    Обычно я запускаю эти две следующие команды перед перезагрузкой: find /var/log/ -type f \( -name "*.gz" -o -name "*.1" -o -name "*.old" \) -delete и find /var/log/ -type f -exec truncate -s 0 {} \; это очищает весь файл / var / log без удаления основных файлов, потому что некоторые файлы там не получаются автоматически сгенерированы снова. – Videonauth 8 November 2017 в 04:05

syslog

Чтобы предотвратить чрезмерно большие файлы журналов в будущем, отредактируйте /etc/logrotate.conf, чтобы ограничить количество и размер файлов журнала. См. [F3] для получения дополнительной информации.

syslog

Чтобы предотвратить чрезмерно большие файлы журналов в будущем, отредактируйте /etc/logrotate.conf, чтобы ограничить количество и размер файлов журнала , Дополнительную информацию см. В man logrotate. Информацию об использовании основного journalctl см. В разделе systemd: Использование журнала. Сведения о том, как уменьшить размер журнала Systemd, см. В журналах Systemd (journalctl) слишком велики и медленны.
1
ответ дан 25 May 2018 в 02:35
  • 1
    Или выключите syslog и используйте журнал. Вещи идут в этом направлении, это всего лишь вопрос времени. – Metta Crawler 24 May 2018 в 13:21

После обнаружения того, что файлы syslog и kern.log увеличиваются, у меня закончилось дисковое пространство. Дисковый менеджер пространства показал мне, что папка /var/log занимает много места. Когда я выполнял команду

tail -15 syslog  

, я обнаружил повторяющиеся ошибки. Также syslog и файл kern.log заняли 19 и 32 G соответственно. (команда для использования диска: du -h filename -h для чтения человеком).

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

Примечание (только предложение):

1) Если вы не знаете о файловой системе Linux, тогда это хорошая ссылка: https://help.ubuntu.com/community/ LinuxFilesystemTreeOverview

2) Дополнительная информация о файлах журнала: https://help.ubuntu.com/community/LinuxFilesystemTreeOverview

Прохождение этих ссылок очистит много понятий.

1
ответ дан 25 May 2018 в 02:35
  • 1
    Спасибо, много полезной информации для начинающего Linux, как я. Информация там ... нахождение это проблема! – B.Tanner 24 May 2018 в 10:47
  • 2
    Найти это тоже проблема. Если вы указали документацию в Google Linux File System, то она также не отображает приведенную выше документацию. Это видно только при вводе документации по дереву файловой системы Linux. Найти подходящее ключевое слово для googling очень сложно для меня. Интересно, что я тоже новичок;) – Delsilon 24 May 2018 в 11:59
  • 3
    Много и много других интересных статей в родительском каталоге этой ссылки, т. Е. help.ubuntu.com/community В течение следующих нескольких дней идет свободное время! – B.Tanner 24 May 2018 в 12:40
  • 4
    Поистине, я не занимался этим. Я чувствую, что нашел золотые вещи. Спасибо, что показал мне эту вещь. В настоящее время я работаю над совершенно другим проектом, но все же Linux все время ел. – Delsilon 24 May 2018 в 13:10

Другие вопросы по тегам:

Похожие вопросы: