Linux: что делать, если /var/log разросся и диск переполнен

Зачем нужен /var/log и почему он разрастается

/var/log — стандартное место, где Linux и сервисы хранят журналы: системные сообщения, аутентификацию, логи веб-сервера, приложений, баз данных и т. д. Когда вы видите «disk full» и подозрение падает на логи, обычно причина в одном из сценариев ниже.

• Сервис «шумит» ошибками (циклические 500/502, падения воркеров, постоянные переподключения к БД).
• Ротация не работает: сломался logrotate, неверные права/владельцы, сервис не переоткрывает файлы после ротации.
• systemd-journald копит журнал без лимитов (особенно при persistent-режиме).
• Двойная запись: сообщения одновременно уходят в journald и в файлы через rsyslog (объём может вырасти в 2 раза).
• Появились «удалённые, но занятые» файлы: процесс продолжает писать в удалённый лог и место не освобождается.

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

Шаг 1. Убедиться, что переполнение связано с /var/log

Начните с общей картины по месту и inode (иногда заканчиваются не гигабайты, а inode):

df -h

df -i

Если заполнен корневой раздел, оцените вклад /var/log и сразу отсортируйте по размеру:

sudo du -xhd1 /var/log | sort -h

Углубляйтесь в подозрительный каталог:

sudo du -xhd1 /var/log/nginx | sort -h

Если «виновник» — один или несколько гигантских файлов, найдите топ-30 по размеру:

sudo find /var/log -xdev -type f -printf '%s %p\n' | sort -n | tail -n 30

Чаще всего «чемпионы» — /var/log/syslog, /var/log/messages, /var/log/auth.log, логи nginx/apache и приложения. Отдельно проверьте systemd-журнал: при persistent-режиме он обычно хранится в /var/log/journal.

Шаг 2. Проверить systemd-journald и быстро освободить место

На systemd первым делом посмотрите, сколько на диске занимает journald:

sudo journalctl --disk-usage

Если там гигабайты, самое безопасное «быстрое» действие — vacuum: journald сам корректно удалит старые сегменты.

sudo journalctl --vacuum-time=7d

Либо ограничьте по размеру:

sudo journalctl --vacuum-size=500M

Когда диск заполнен на 100%, часть команд может падать из-за невозможности создать временные файлы. Цель — освободить хотя бы десятки мегабайт (часто vacuum journald помогает быстрее всего), после чего возвращаться к диагностике.

Чтобы проблема не повторялась, задайте лимиты в /etc/systemd/journald.conf:

sudoedit /etc/systemd/journald.conf

[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=7day
Compress=yes

Примените изменения:

sudo systemctl restart systemd-journald

Если журнал хранится persistently (каталог /var/log/journal существует), лимиты особенно важны на небольших дисках и небольших VPS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Шаг 3. Срочно уменьшить конкретный лог: truncate вместо rm

Когда место нужно «прямо сейчас», безопаснее всего обнулить конкретный лог, не меняя inode и права. Для этого используйте truncate:

sudo truncate -s 0 /var/log/nginx/access.log

Почему не rm? Многие демоны держат открытый файловый дескриптор. Если удалить файл, процесс продолжит писать в уже удалённый inode, и место на диске не освободится до перезапуска процесса. Это выглядит как «я удалил лог, а места не прибавилось».

Если нужно сохранить «хвост» для диагностики, сначала снимите последние строки, затем обнулите:

sudo tail -n 20000 /var/log/syslog > /tmp/syslog.tail

sudo truncate -s 0 /var/log/syslog

Сохранённый хвост можно положить рядом отдельным файлом:

sudo cp /tmp/syslog.tail /var/log/syslog.tail

Шаг 4. «Удалил лог, а место не вернулось»: найти deleted-but-open через lsof

Если кто-то удалил крупный файл, а место не освободилось, почти наверняка процесс продолжает держать дескриптор. Проверьте открытые удалённые файлы:

sudo lsof +L1 | grep -E '(/var/log|deleted)'

Если видите строки с (deleted) и большим размером, действуйте так:

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

Примеры:

sudo nginx -s reopen

sudo systemctl restart nginx

sudo systemctl restart rsyslog

Смысл один: найти процесс, который держит удалённый лог, и заставить его отпустить дескриптор.

Шаг 5. Проверить logrotate: запускается ли ротация и нет ли ошибок

logrotate — стандартная ротация файловых логов. Если она «застряла», файлы растут бесконечно.

Убедитесь, что расписание работает (в зависимости от дистрибутива это может быть systemd timer):

systemctl list-timers | grep -E 'logrotate'

Посмотрите ошибки последнего прогона:

sudo journalctl -u logrotate --no-pager -n 200

Диагностика без изменений (dry-run):

sudo logrotate -d /etc/logrotate.conf

Принудительный прогон (делайте осознанно, лучше в окно работ):

sudo logrotate -f /etc/logrotate.conf

Частые причины проблем:

• права на каталог/файл не позволяют создать новый лог;
• после ротации сервис не переоткрывает лог (нужен корректный postrotate);
• неуместный copytruncate (или наоборот, он нужен, а его нет);
• слишком редкая ротация (например, weekly при большом трафике).

Пример правила для nginx (адаптируйте под свои пути и сервис):

/var/log/nginx/*.log {
  daily
  rotate 14
  missingok
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
    /usr/sbin/nginx -s reopen
  endscript
}

copytruncate иногда спасает, когда сервис не умеет reopen, но это компромисс: при высокой нагрузке возможна потеря части строк. Если есть возможность, лучше настроить штатное переоткрытие.

Шаг 6. rsyslog и «шумные» источники: найти, кто генерирует объём

Если логи в файлах (syslog-подобные), полезно понять, какой процесс чаще всего фигурирует в сообщениях. Простой грубый подсчёт по «пятому полю» (часто там имя процесса) может быстро подсветить виновника:

sudo awk '{print $5}' /var/log/syslog 2>/dev/null | sort | uniq -c | sort -n | tail -n 30

Для journald можно прикинуть самые повторяющиеся сообщения за период (подход приблизительный, но часто помогает):

sudo journalctl --since '1 hour ago' --no-pager | awk '{$1=$2=$3=""; print}' | sort | uniq -c | sort -n | tail -n 30

Если виноват конкретный unit, нередко эффективнее временно снизить уровень логирования в конфиге приложения и параллельно чинить первопричину, чем бесконечно «подчищать» последствия.

Отдельно проверьте, нет ли двойной записи: сервис пишет в stdout/stderr (это попадает в journald), а затем те же сообщения ещё и складываются rsyslog в файл. В таких конфигурациях объём логов растёт кратно.

Если вам нужно централизованно собирать systemd-журналы с нескольких серверов, пригодится материал: настройка systemd-journal-remote для централизованных логов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Шаг 7. Профилактика: лимиты, алерты и быстрые «красные флаги»

• Поставьте лимиты journald и периодически проверяйте journalctl --disk-usage.
• Проверьте правила logrotate для ключевых сервисов (nginx/apache, php-fpm, приложения). На большом трафике чаще подходит daily или ротация по size.
• Добавьте мониторинг места и inode: пороги 70/85/95% плюс алерт на быстрый рост /var/log.
• Ищите первопричину: если /var/log раздувается, значит что-то работает в ошибочном режиме. Логи — симптом, а не болезнь.

Если вы регулярно упираетесь в место из-за логов, почти всегда это сочетание отсутствия лимитов/ротации и постоянной ошибки в сервисе. Исправление причины обычно сокращает объём логов на порядки.

На небольших дисках (типично для VPS) особенно важно заранее закладывать запас под логи и кэш. Если проект вырос и место стало узким горлышком, иногда проще и дешевле по времени увеличить диск на VDS, чем регулярно тушить «disk full» вручную.

Короткий чек-лист: «disk full /var/log» за 10 минут

1. df -h и df -i — понять, что именно закончилось.
2. sudo du -xhd1 /var/log | sort -h — найти каталог-источник.
3. sudo journalctl --disk-usage — оценить вклад journald.
4. sudo journalctl --vacuum-size=500M или sudo journalctl --vacuum-time=7d — быстро освободить место.
5. sudo find /var/log -xdev -type f -printf '%s %p\n' | sort -n | tail -n 30 — топ файлов.
6. sudo truncate -s 0 FILE — точечно уменьшить самый большой лог.
7. sudo lsof +L1 — проверить «deleted but open».
8. sudo logrotate -d /etc/logrotate.conf и логи logrotate — проверить ротацию.

Итоги

/var/log — важный источник диагностики, но без лимитов и ротации он легко превращается в причину аварии. В боевой ситуации используйте связку: du для поиска виновника, journalctl --disk-usage и vacuum для journald, truncate для срочного освобождения места, lsof для скрытых «удалённых» файлов и настройку logrotate/rsyslog для профилактики.