Linux: служба не запускается из-за переполненного диска или inode
Когда служба Linux перестаёт запускаться, а в журнале появляются «No space left on device», «Failed to write», «Read-only file system» или ошибки создания временного файла, важно не спешить с удалением содержимого диска. Отсутствие свободного места — не всегда нехватка гигабайтов. На некоторых файловых системах заканчиваются inode, исчерпывается квота, либо приложение пишет не в тот раздел, который вы проверяете. Вначале нужно определить, какой ресурс закончился и где именно, а уже затем безопасно освобождать место.
Как понять, что причина действительно в хранилище
Откройте терминал и узнайте точное имя проблемной службы, например example.service. Команда systemctl status example.service покажет текущее состояние unit и последние диагностические сообщения. Отдельно используйте journalctl -u example.service -b --no-pager -n 100: она читает последние записи службы в текущем цикле загрузки, не меняя данные на диске. Если сервис не запускается после перезагрузки, полезно уточнить, был ли отказ ещё при прошлом запуске; команды с выбором другого boot используйте только после проверки списка доступных загрузок.
Не каждый код failed означает нехватку места. Различайте отказ чтения конфигурации, неверные права, занятую сеть, недоступную базу и сообщение об отсутствии свободного пространства. Иногда переполнение диска — лишь сопутствующий симптом: приложение не может записать отчёт об ошибке, хотя первоначальная проблема была другой.
Проверяем байты, inode и точку монтирования
Сначала выполните df -h, затем df -i. Первая команда показывает использование места в понятных единицах, вторая — использование inode, то есть объектов файловой системы, где этот учёт поддерживается. Сравните значения для того пути, куда пишет сервис, а не просто для корневого раздела. Команда df -h /var/lib/example помогает определить раздел по конкретному каталогу, если он существует. Для inode используется тот же принцип: df -i /var/lib/example.
Типичная ситуация: в df -h свободно несколько гигабайтов, но df -i показывает практически 100% занятых inode. Тогда создание нового файла может не удаться, даже если свободные байты ещё остались. Другая ситуация: переполнен отдельный том /var или /home, а пользователь проверял только /. Также учитывайте контейнеры, snap-пакеты, виртуальные машины и подключённые сетевые файловые системы: их данные могут находиться на другом разделе или иметь собственные ограничения.
Если файловая система смонтирована только для чтения, это уже отдельный сценарий: освобождение места не обязано исправить проблему. Посмотрите сообщения ядра и состояние накопителя, не форсируйте запись и не отключайте защитные проверки. При признаках отказа SSD приоритет — резервная копия и диагностика, а не очистка ради запуска приложения.
Как найти источник роста без разрушительных команд
Для первичной оценки начните с отображения размеров каталогов, например du -sh /var/log /var/cache /var/lib, если права позволяют и вы понимаете назначение каталогов. Эта команда читает метаданные, но может долго работать на большом дереве или сетевом томе. Она показывает суммарные размеры; поиск места не следует начинать с рекурсивного удаления. Сравните, какие каталоги росли перед сбоем: журнал приложения, кэш сборки, временные файлы, контейнерные слои, бэкапы или данные самой базы.
Особенно важно различать много небольших файлов и один очень большой файл. Миллионы маленьких файлов объясняют исчерпание inode. Один огромный лог может объяснять заполнение байтов. При этом запись в открытый, но удалённый процессом файл может продолжать занимать место до закрытия файлового дескриптора; в таком случае отсутствие больших файлов при полном диске требует отдельного разбора. Не отправляйте сервису сигнал перезапуска, если он удерживает важные незавершённые операции, пока не выяснены последствия.
Почему нельзя просто выполнить rm -rf
Удаление наугад из /var/lib, /etc, папки базы данных или каталога контейнеров может привести к потере пользовательских данных, настроек, токенов и истории операций. Команда удаления не спрашивает, какие файлы нужны запущенному процессу. Даже на тестовом ноутбуке лучше сначала сохранить список файлов, оценить назначение каталога и убедиться, что у приложения есть документированный способ очистки.
Для журналов systemd рассмотрите штатные средства управления размером journal после сохранения нужной диагностики. Для пакетных менеджеров применяйте официальные команды очистки соответствующего дистрибутива, а не удаление базы менеджера вручную. Для Docker, Podman, PostgreSQL и других систем используйте собственные механизмы обслуживания и понимаемые правила хранения. Удаление контейнерных образов и томов не эквивалентно удалению кэша: в томах могут находиться реальные данные.
Безопасная последовательность восстановления
Шаг 1. Зафиксируйте момент отказа, имя unit, сообщения systemctl и journalctl. Сохраните важные журналы в место, где есть свободное пространство, либо на внешний носитель. Журналы могут содержать персональные сведения или токены — перед пересылкой их нужно обезличить.
Шаг 2. Определите точный путь записи и его файловую систему через df. Сравните занятость байтов и inode. Если причина — квота пользователя, исправление требует владельца учётной записи или администратора, а не чистки чужих каталогов.
Шаг 3. Установите владельца файлов и назначение каталогов с помощью чтения метаданных. Уточните, не пишет ли сервис во временный каталог, в неожиданное место из-за символьной ссылки или подмены точки монтирования. Если затронута рабочая база данных, перед любым вмешательством подготовьте резервную копию штатным способом и убедитесь, что она пригодна для восстановления.
Шаг 4. Освободите только подтверждённо временное пространство поддерживаемыми средствами приложения. После действия повторите df -h и df -i для целевого пути, затем проверьте логи. Не удаляйте одновременно несколько независимых категорий файлов: иначе нельзя будет установить, какая операция помогла.
Шаг 5. Если объём свободного пространства достаточный и системное состояние безопасно, попытайтесь штатно запустить одну проблемную службу. Посмотрите её статус и новые сообщения, убедитесь, что она не ушла в цикл падений. Проверяйте не только факт active, но и работоспособность пользовательской операции — если она доступна для безопасного теста.
Если заполнение повторяется
Повторное заполнение обычно означает, что причина роста не устранена. Настройте разумные ограничения журналирования, ротацию логов и мониторинг именно нужного раздела и inode. Для приложения с постоянно растущими временными файлами уточните документацию разработчика. Для ноутбука с несколькими ОС проверьте, не относится ли заполнение к разделу другой системы, который Linux лишь монтирует.
Не используйте автоматическую ежечасную очистку неизвестных директорий как замену диагностике. Она может стирать доказательства и периодически повреждать работающие сервисы. Если рост начался после обновления, не откатывайте сразу весь дистрибутив: установите, что именно стало писать больше данных.
FAQ
Почему df показывает свободные гигабайты, а файл создать нельзя? Возможно, закончились inode, действует квота или программа пишет на другой том. Проверяйте именно путь записи.
Можно ли удалить папку /var/log целиком? Нет. В ней хранятся полезные диагностические данные, а часть файлов контролируется системными службами. Применяйте штатные средства управления журналами.
Что делать при ошибках ввода-вывода и монтировании read-only? Остановить разрушительные попытки очистки, защитить важные данные и исследовать состояние накопителя отдельно.