Var log messages linux можно удалить

Can I delete /var/log files due to low root space?

Judging by a posted message on ubuntu.org forums, I found that I have a .log file in /var/log at 22 GB in size! My root is an 82 GB partition and Disk Analyser shows the offender to be in log. The system root was installed circa 8 months ago, so clearly this is not a good thing in creating a 22 GB log on an 82 GB root partition. Is it safe to delete the log file or please advise on the correct safe procedure to cleanse it without messing up my system. I presume it may be ok, but would like some other opinions before I do the task of delete.

An alternative is to compress it using gzip or bzip2 — though this requires temporarily having enough space to hold both uncompressed and compressed copies of the file. Log files tend to have a lot of redundancy, so they should compress quite well (probably better than 90%).

5 Answers 5

It is generally safe to delete log files. The only disadvantage associated with doing so is that you may not be able to examine the log, if you’re troubleshooting some other problem later. Since new logs are automatically generated, even this disadvantage is short-lived.

Most logs are deleted automatically (after being rotated by compression and renaming, and kept a while in that archived format). If you have a log that’s expanded faster than Ubuntu is deleting it, it’s unlikely that you’ll experience any problems from deleting it manually.

However, if you have a log file that’s 22 gigs in size, something very strange is happening, and it would be worthwhile to investigate that. I recommend editing your question again to include a link to the Ubuntu Forums thread you’re talking about, and also to include the full name of the 22 GB log file.

Источник

Какие файлы можно удалить при нехватке места на диске Linux

То есть бывают действительно критические ситуации — в этих условиях перестают нормально работать многие программы и службы. Поэтому задача становится следующей: срочно любой ценой освободить место на диске, чтобы можно было продолжить обслуживание системы и перейти ко второму этапу — поиску директорий и файлов, которые привели к этой проблеме из-за того, что стали занимать слишком много места.

Предупрежу заранее: следующие команды хотя в основном и удаляют бесполезные файлы, после их выполнения могут привести к следующим последствиям:

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

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

1. Удаление временных файлов

Файлы в папке /tmp/ будут удалены в любом случае при следующей перезагрузки системы. То есть с одной стороны их можно удалить достаточно безболезненно:

НО: может быть нарушена работа программ, которые запущены в настоящее время и которые сохранили какие-то данные в папку /tmp/.

2. Удаление файлов кэширования

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

Для удаления кэша шрифтов:

sudo rm -rf /var/cache/fontconfig/

Для удаления кэша установочных пакетов (на Debian, Linux Mint, Ubuntu, Kali Linux и их производных):

Для удаления кэша установочных пакетов (на Arch Linux, BlackArch и их производных):

sudo rm -rf /var/cache/pacman/

Удаление кэша справочных страниц:

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

3. Удаление логов (журналов)

В этой папке (/var/log/) можно удалить практически все файлы, но старайтесь сохранить структуру папок, поскольку некоторые приложения после удаления здесь папки не в состоянии создать её второй раз…

На веб-серверах могут разрастись слишком сильно журналы веб-сервера.

Для удаления логов Apache на Debian, Linux Mint, Ubuntu, Kali Linux и их производных:

Для удаления логов Apache на Arch Linux, BlackArch и их производных:

Чтобы сервер начал создавать новые файлы журналов и записывать в них, нужно перезапустить службу веб-сервера.

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

4. Очистите корзину

Этот совет больше для настольных систем. Файлы, которые вы удалили в графическом интерфейсе рабочего стола, попадают в папку ~/.local/share/Trash/files/, вы можете проанализировать их и при желании удалить (второй раз):

ncdu ~/.local/share/Trash/files/

5. Удаление ненужных файлов исходного кода заголовков ядра

Следующее актуально только для Debian, Linux Mint, Ubuntu, Kali Linux и их производных. Проверьте папку /usr/src/, там будут подпапки вида linux-headers- — большинство из них можно удалить — оставьте только ту, номер которой соответствует текущему ядру системы — обычно это самый последний номер выпуска.

6. Удаление осиротевших пакетов

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

На Debian, Linux Mint, Ubuntu, Kali Linux и их производных удалить ненужные пакеты можно следующим образом:

Для Debian и производных предыдущая команда абсолютно безопасна.

В Arch Linux и производных список осиротевших пакетов можно увидеть следующим образом:

Прежде чем переходить к их автоматическому удалению, настоятельно рекомендуется изучить этот список!

Для рекурсивного удаления сироток и их конфигурационных файлов в Arch Linux и производных:

sudo pacman -Rns $(pacman -Qtdq)

Если осиротевшие пакеты не были найдены, pacman завершит работу с ошибкой: ошибка: не задано целей (для справки используйте -h). Это ожидаемо, поскольку pacman -Rns не получил аргументов.

7. Очистка журналов systemd

Со временем, в некоторых системах логи системы начинают занимать гигабайты на жёстком диске. Просмотреть журналы и освободить место вы можете с помощью команды journalctl, подробности смотрите в статье «Как использовать journalctl для просмотра системных логов Linux».

Чтобы увидеть, сколько место занимают журналы, выполните:

Чтобы удалить все записи, оставив только записей на 100 мегабайт, выполните:

journalctl --vacuum-size=100M

Либо для удаления всех записей в системном журнале, старше одной недели:

journalctl --vacuum-time=1weeks

8. Файлы в директории /lost+found

В папку /lost+found сохраняются файлы, которые были найдены после проверки файловой системы диска. Обычно такие проверки выполняются после внезапной перезагрузки системы или в случае признаков проблем с диском.

Найденные файлы обычно повреждены. Их цель — сохранить данные, которые в случае исправления ошибок на файловой системе были бы совсем утеряны.

Папка /lost+found может быть пустой (если не было проблем с диском). В случае если там есть файлы, то вы можете их просмотреть и, при желании, удалить.

9. Очистка PHP сессий

Иногда веб-приложений из-за бага могут создать бесчисленное количество сессий. Проверьте директорию /var/lib/php/sessions/ на предмет слишком большого количества файлов.

(БОНУС) 10. Проанализируйте файлы Docker

Не удаляйте бездумно файлы Docker. Я привожу пример этой директории только по той причине, что она привлекла моё внимание из-за просто фантасмагоричного размера — и это при том, что я Docker’ом фактически не пользуюсь — буквально несколько раз попробовал, чтобы увидеть, что это такое.

Самой большой папкой является /var/lib/docker/overlay2/. Для анализа занимаемого места на диске выполните:

Заключение

Итак, мы рассмотрели, какие файлы можно удалить из Linux практически без потери информации. Кроме рассмотренных директорий, которые можно очистить как на удалённой системе с веб-сервером, так и на домашнем компьютере, пользователям с графическим рабочим столом следует обратить внимание на такие директории как:

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

Если я пропустил какие-то директории с файлами, которые можно безболезненно удалить, то пишите их в комментариях!

Связанные статьи:

Источник

/var/log/messages.log

Ребят, в /var забит(2гб), смотрю что много занимает места, в итоге файл /var/log/messages.log занимает 1.2гб. Читаю что это — (/var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого) Можно ли его удалить чтоб очистить директорию? После перезагрузки он имеет такой же объем, хотя в описании написано с момента запуска ядра

После перезагрузки он имеет такой же объем, хотя в описании написано с момента запуска ядра

В него пишутся сообщения с момента запуска, но это значит что он при старте обнуляется.

gruy ★★★★★ ( 21.05.21 10:10:35 MSK )
Последнее исправление: gruy 21.05.21 10:12:12 MSK (всего исправлений: 1)

truncate -s 1M /var/log/messages

Так хоть из любопытства загляни в него. Узнаешь, что в нем, и с какого по какой момент.

Можно, но 1.2 гига логов — это ненормально, поэтому лучше сначала посмотреть, кто именно столько пишет в журнал и по какой причине, а плотом устранить эту причину.

Да там много сообщений от connect to udp на один и тот же хост, я думаю это не сильно важно

Спасибо. хороший способ. Еще нашел вроде такой способ mv /var/log/messages /var/log/messages.old cat /dev/null > /var/log/messages

может стоит перейти на использование logrotate?

sigurd ★★★★★ ( 21.05.21 11:19:13 MSK )
Последнее исправление: sigurd 21.05.21 11:26:04 MSK (всего исправлений: 1)

За какое время там эти 1.2гб накопились? Если за год — то сойдёт (хотя у меня весь /var/log за год занимает 50мбайт, но большинство логов уже ротировано и сжато в gzip), если за пару дней — надо настроить систему нормально, чтоб логи бесполезные не флудились (а полезные — записывались и ты мог их смотреть в этом файле).

Ну и 2гб для /var это явно мало в современных системах, такое 15 лет назад нормой было когда весь диск на всё например 40гб (а то и меньше) и лишний гигабайт тратить не хотелось. Ставь не меньше 4гб.

может стоит перейти на использование logrotate?

Так вроде он по умолчанию должен вставать и крутить логи. Разве что старый админ, что то накрутил, а новый (admin. ) не в курсе.

Очень плохие настройки, хотя и по дефолту везде что-то похожее стоит.

weekly rotate 100 size 100M 

Диски (даже SSD) сейчас достаточно дешёвые, чтобы позволить хранить всё это (не смотрите на 100M, это просто на всякий случай ограничитель, по факту так много там не может быть если всё в порядке), а для диагностики мелких не сразу замеченных (за гуем) проблем может быть очень полезно.

А для чего-то редкоиспользуемого можно вообще хоть yearly поставить, чтобы не мусорить файлами по 1 строчке раз в неделю.

firkax ★★★★ ( 21.05.21 12:56:38 MSK )
Последнее исправление: firkax 21.05.21 12:58:18 MSK (всего исправлений: 3)

Источник