Почему каждый администратор Linux должен следить за каталогом /var
Администраторы Linux часто следят за загрузкой процессора, использованием памяти и временем безотказной работы. Эти показатели важны. Однако использование диска приводит к большему количеству сбоев, чем ожидают многие команды. Один каталог заслуживает особого внимания: /var.
Если /var растёт бесконтрольно, это может незаметно нарушить стабильность системы и даже привести к сбою вашего сервера Linux. Давайте разберёмся, почему это происходит и как этого избежать.
Что такое /var и почему это важно
В каталоге /var хранятся данные, которые изменяются во время работы системы. К ним относятся:
- Журналы
- Базы данных
- Кэши
- Буферные файлы
- Состояние во время выполнения
Поскольку объем этих данных продолжает расти, /var требует регулярной проверки. Если администраторы игнорируют это требование, проблемы возникают без предупреждения.
Журналы растут быстрее, чем вы думаете
Большинство системных и служебных журналов хранятся в:
/var/log/var/log/journal(когда systemd использует постоянное хранилище)
Сервисы постоянно ведут журналы. Со временем даже обычные журналы могут занимать гигабайты памяти. Ведение журналов отладки усугубляет ситуацию. Если нарушается ротация журналов или правила хранения слишком мягкие, использование диска быстро увеличивается.
Этот риск возрастает, когда /var использует пространство совместно с корневой файловой системой. В этом случае одна «шумная» служба может заполнить весь диск.
Что происходит, когда /var заполняется
Полное /var не всегда приводит к сбою системы. Тем не менее это часто вызывает серьёзные проблемы. Вот что происходит на самом деле.
Ведение журнала перестаёт работать
Когда на диске заканчивается место, systemd не может записывать новые записи в журнал. В результате вы теряете логи именно тогда, когда они вам больше всего нужны. Устранение неполадок становится сложнее и занимает больше времени.
Базы данных могут выйти из строя
Многие базы данных по умолчанию хранят данные в /var/lib по умолчанию. Например, MySQL, MariaDB и PostgreSQL. Если /var заполняется и база данных находится там, операции записи завершаются ошибкой. Транзакции прерываются. В некоторых случаях база данных останавливается.
Этого не происходит, если база данных использует другую файловую систему. Расположение имеет значение.
Приложения становятся нестабильными
Приложения часто записывают логи, файлы состояния и данные кэша в папку /var. Когда на диске заканчивается место, поведение приложений меняется. Некоторые приложения вылетают. Другие работают медленнее или выдают ошибки. Каждое приложение реагирует по-своему, что усложняет диагностику.
SSH по-прежнему работает, но с ограничениями
SSH не прекращает принимать соединения только потому, что /var/log заполнен. Однако он может не записывать данные для входа или журналы аутентификации. В крайних случаях, когда диск переполнен, это может повлиять на удалённый доступ. Тем не менее, если /var заполнен, это не приводит к отключению SSH.
Почему это может привести к простою
Полный /var часто приводит к простоям, когда:
- Он использует пространство вместе с
/ - От него зависят критически важные службы
- Оповещения о состоянии диска отсутствуют
Не каждая система выходит из строя одинаково. Однако исчерпание диска всегда увеличивает риск. Это делает профилактику необходимой.
Основные команды Linux для мониторинга и контроля /var использования диска
Для управления вам не нужны сложные системы мониторинга /var. Несколько правильно подобранных команд и привычек предотвращают большинство инцидентов, связанных с диском. Регулярно используйте эти инструменты.
1. Найдите то, что растет внутри /var
Начните с определения местоположения крупнейших пользователей пространства.
du -h --max-depth=1 /var | sort -h
Эта команда выводит размеры каталогов в понятном порядке. Она помогает быстро выявить проблемы, например, слишком большие журналы или переполненные кэши.
Пример вывода:
4,0 КБ /var/local 4,0 КБ /var/opt 92 КБ /var/tmp 6,9 МБ /var/backups 7,3 МБ /var/spool 82 МБ /var/mail 4,0 ГБ /var/log 8,2 ГБ /var/lib 19 ГБ /var/cache 31 ГБ /var
Для более глубокого обзора:
du -h --max-depth=1 /var/log | sort -h
Здесь речь идёт только о журналах, которые чаще всего становятся причиной нехватки места на диске.
2. Проверьте использование файловой системы, а не только размер каталога
Иногда место заканчивается из-за зарезервированных блоков или исчерпания индексных дескрипторов.
df -h /var
Пример вывода:
Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 456G 273G 161G 63% /
Здесь показано общее, используемое и свободное пространство.
df -i /var
Это позволяет проверить использование индексных дескрипторов. Миллионы крошечных файлов могут привести к сбою системы, даже если с дисковым пространством всё в порядке.
3. Контролируйте размер и ограничения журнала systemd
Журналы systemd часто незаметно увеличиваются в размере.
logrotate -d /etc/logrotate.conf
Чтобы ограничить будущий рост:
journalctl --vacuum-size=500M
Или удалите старые записи по возрасту:
journalctl --vacuum-time=14d
Эти команды сокращают использование дискового пространства без остановки ведения журнала.
4. Убедитесь, что ротация журналов действительно работает
Logrotate есть в большинстве систем, но при неправильной настройке он ничего не делает.
logrotate -d /etc/logrotate.conf
Это запускает logrotate в режиме отладки и показывает, что он мог бы сделать.
logrotate -f /etc/logrotate.conf
Это принудительная ротация. Используйте её, когда журналы уже стали слишком большими.
Также убедитесь, что ротация выполняется по расписанию:
systemctl status logrotate.timer
5. Проверьте, не занимают ли удалённые файлы место в памяти
Распространённая скрытая проблема возникает, когда процесс оставляет удалённый файл открытым.
lsof +L1
Здесь показаны файлы, удалённые с диска, но всё ещё занимающие место. Перезапуск соответствующей службы обычно мгновенно освобождает место.
6. Проверьте базу данных и служебные данные
Крупные службы часто находятся в папке /var/lib.
du -sh /var/lib/*
Это позволяет быстро выявить растущие базы данных, данные в контейнерах или состояние пакетов.
Если вы используете контейнеры:
du -sh /var/lib/docker
или
du -sh /var/lib/containers
Контейнеры часто растут быстрее, чем логи.
7. Безопасная очистка кэша менеджера пакетов
Кэш пакетов может со временем увеличиваться.
В Debian и Ubuntu:
apt autoremove apt clean
В RHEL, CentOS и Rocky Linux:
dnf clean all
Эти команды освобождают место, не нарушая работу системы.
8. Добавьте простые оповещения о состоянии диска
Даже базовые оповещения помогают избежать чрезвычайных ситуаций.
Для быстрой проверки вручную:
df -h | grep /var
Для автоматизации добавьте задание cron или правило мониторинга, которое будет предупреждать вас, когда использование ресурсов превысит 70–80 %. Ранние предупреждения дают вам время действовать спокойно.
Заключение
Большинство сбоев в работе Linux не начинаются с резкого повышения нагрузки на процессор или память. Они начинаются незаметно. Журнал растёт быстрее, чем ожидалось. Кэш никогда не очищается. База данных записывает на один файл больше. Всё это происходит в одном месте: /var.
Когда каталог /var заполняется, системы теряют журналы, сервисы выходят из строя, а восстановление становится сложнее. Именно поэтому опытные администраторы Linux следят за /var до того, как возникнут проблемы.
С помощью этих практичных команд Linux вы сможете эффективно отслеживать логи, журналы и служебные данные в /var и предотвращать перегрузку диска и даже сбои в работе сервера.
Эти простые инструменты командной строки превращают незаметный рост в видимые сигналы. Запускайте их почаще. Получайте оповещения заранее. Вы избежите сбоев и ночной работы по восстановлению.
Редактор: AndreyEx
