Как безопасно очистить логи Ubuntu и освободить место на диске

Введение / Зачем это нужно

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

Этот гайд покажет, как безопасно очистить как классические текстовые логи, так и журнал systemd-journald. Вы научитесь отличать критические логи от устаревших, освоите основные команды и поймёте, как настроить автоматическую ротацию для предотвращения проблемы в будущем.

Требования / Подготовка

Перед началом убедитесь, что:

1. У вас есть доступ к терминалу и права sudo (администратора).
2. Вы работаете на Ubuntu 22.04+ или совместимом дистрибутиве (Debian, Linux Mint).
3. Вы понимаете, что нельзя удалять файлы auth.log, syslog или kern.log без понимания последствий. Мы будем удалять только устаревшие (архивные) записи.

Важно: Если вы на сервере, убедитесь, что у вас есть свободное место для выполнения операций (хотя бы 100-200 МБ).

Шаг 1: Оцените текущее использование места логами

Сначала узнайте, что именно занимает место в /var/log.

# Посмотрите общий размер директории /var/log
sudo du -sh /var/log

# Увидите топ-10 самых больших файлов и директорий внутри /var/log
sudo du -ah /var/log 2>/dev/null | sort -rh | head -n 20

Что смотреть:

• journal/ — это бинарные логи systemd-journald. Их размер можно проверить отдельно: sudo journalctl --disk-usage.
• Файлы с расширением .gz или .1, .2 — это уже сжатые ротированные логи. Их можно удалять.
• Крупные файлы без расширения (например, syslog, kern.log) — это активные логи. Не удаляйте их целиком! Их нужно либо архивировать через logrotate, либо очищать содержимое (см. Шаг 4).

Шаг 2: Очистите журнал systemd (journalctl)

Это самый безопасный способ управлять системным журналом. journalctl знает о своей внутренней структуре.

# Очистить журналы старше 7 дней
sudo journalctl --vacuum-time=7d

# Очистить журналы, оставив не более 100МБ
sudo journalctl --vacuum-size=100M

# Очистить журналы, оставив не более 10 файлов (сегментов)
sudo journalctl --vacuum-files=10

Какой метод выбрать?

• --vacuum-time — лучше всего, если вы хотите хранить логи за последние N дней.
• --vacuum-size — жёсткий лимит по месту. Система удалит самые старые записи, пока не упадёт ниже порога.
• --vacuum-files — ограничивает количество сегментов файлов журнала.

💡 Совет: После очистки проверьте размер: sudo journalctl --disk-usage.

Шаг 3: Очистите старые сжатые логи в /var/log

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

# Перейдите в директорию логов
cd /var/log

# Найдите и удалите все .gz файлы старше 30 дней (параметр -mtime +30)
sudo find . -name "*.gz" -type f -mtime +30 -delete

# Также удалите старые ротированные файлы без сжатия (например, .1, .2)
sudo find . -name "*.[0-9]" -type f -mtime +30 -delete

Безопасная альтернатива (рекомендуется): Вместо -delete сначала посмотрите, что будет удалено:

sudo find . -name "*.gz" -type f -mtime +30 -ls

Убедитесь, что в списке нет нужных вам архивов (например, старые логи конкретного приложения, которые вы хотите сохранить).

Шаг 4: Очистите текущие логи приложений (осторожно!)

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

# Очистить содержимое файла, не удаляя сам файл (самый безопасный способ)
sudo truncate -s 0 /var/log/syslog
sudo truncate -s 0 /var/log/kern.log
# ... и другие активные логи, которые вы хотите сбросить

# Или с помощью команды cat (перенаправление в /dev/null)
sudo cat /dev/null > /var/log/syslog

⚠️ Важно: Не выполняйте эту операцию с файлами auth.log или faillog на production-сервере без крайней необходимости — там хранятся записи о входе и попытках доступа.

Шаг 5: Проверьте и настройте logrotate для будущего

logrotate — это демон, который автоматически ротирует, сжимает и удаляет старые логи. Убедитесь, что он работает и настроен адекватно.

# Проверьте конфигурацию logrotate (основной файл)
cat /etc/logrotate.conf

# Посмотрите конфигурации для конкретных пакетов в /etc/logrotate.d/
ls -la /etc/logrotate.d/

# Проверьте, когда последний раз работал logrotate
sudo ls -la /var/lib/logrotate/status

Как ужесточить политику? Например, для логов syslog и kern.log (конфиг /etc/logrotate.d/rsyslog):

/var/log/syslog
/var/log/kern.log
{
    rotate 7          # Хранить 7 архивов (недель)
    daily             # Ротировать каждый день
    compress          # Сжимать
    delaycompress     # Сжимать не сразу, а на следующем цикле
    missingok         # Не падать, если файл отсутствует
    notifempty        # Не ротировать пустые файлы
    create 640 syslog adm  # Создавать новый файл с этими правами
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Измените значение rotate (например, на 4 для хранения 4 дней) и выполните sudo logrotate -f /etc/logrotate.conf для принудительного применения.

Проверка результата

1. Для journalctl: sudo journalctl --disk-usage — размер должен значительно уменьшиться.
2. Для /var/log: sudo du -sh /var/log — общий размер должен быть меньше.
3. Для конкретных файлов: ls -lh /var/log/*.gz — список архивных логов должен содержать только свежие файлы.
4. Убедитесь, что система работает: Попробуйте выполнить команду, которая пишет в лог (например, sudo systemctl status), и проверьте, что новый лог-файл создаётся: ls -lh /var/log/syslog.

Возможные проблемы

• "Permission denied" при удалении файлов: Убедитесь, что вы используете sudo. Некоторые файлы в /var/log могут принадлежать другим пользователям (например, root или syslog).
• Место не освободилось после удаления файлов: Возможно, процесс (демон) держит открытый дескриптор на удалённом файле. Решение: Перезапустите соответствующий сервис (например, sudo systemctl restart rsyslog для классических логов) или sudo systemctl restart systemd-journald для journald. Или выполните sudo logrotate -f.
• Система не пишет логи после очистки: Вы могли случайно удалить активный лог-файл, а не его содержимое. Решение: Перезапустите службу, которая в него писала (например, sudo systemctl restart rsyslog). Она создаст файл заново.
• Logrotate не работает: Проверьте, запущен ли демон cron (он отвечает за ежедневный запуск logrotate): sudo systemctl status cron. Также проверьте конфигурационные файлы в /etc/logrotate.d/ на синтаксис.

Дополнительные рекомендации

• Мониторинг: Добавьте простой скрипт в cron для мониторинга места в /var/log и отправки уведомления, если оно превышает, например, 80%.
• Целевые приложения: Для логов конкретных приложений (nginx, mysql, docker) настройте их собственную ротацию через logrotate или встроенные настройки самого ПО. Конфиги обычно лежат в /etc/logrotate.d/.
• Журнал systemd: Настройте SystemMaxUse, MaxRetentionSec и MaxFileSec в /etc/systemd/journald.conf для глобального контроля над journald. После изменений выполните sudo systemctl restart systemd-journald.
• Безопасность: Если вы администрируете сервер, никогда не удаляйте auth.log и secure без снятия копии для расследования инцидентов. Очищайте только старые архивные версии.

Следуя этим шагам, вы сможете поддерживать директорию /var/log в чистоте, предотвращая проблемы с дисковым пространством, и при этом не нарушив работу системы.