Установка остановилась из-за диска: диагностируем причину, а не симптом

Сообщение «недостаточно места» кажется очевидным: нужно удалить файлы или увеличить диск. На практике оно часто скрывает совсем другую проблему. Свободные гигабайты могут находиться на соседней файловой системе, временный каталог может быть отдельным маленьким разделом, а иногда заканчиваются не байты, а inode — записи, без которых Linux не создаст даже крошечный файл. Поэтому полезная диагностика начинается не с очистки, а с карты размещения.

AiHummer устанавливается напрямую в Linux под управлением systemd, без Docker. Основной сервис, PostgreSQL и дополнительные компоненты используют реальные каталоги хоста. Это делает устройство прозрачным, но означает, что проверять нужно именно те файловые системы, на которых находятся домашний каталог пользователя установки, временные файлы, база данных, журналы и резервные копии. Общая цифра «на сервере свободно 40 ГБ» ничего не доказывает, если нужный раздел заполнен.

Шаг 1. Зафиксируйте ошибку и точный путь

Не запускайте установку снова десять раз подряд. Скопируйте последнюю осмысленную строку ошибки, время и этап: скачивание релиза, распаковка, установка PostgreSQL, миграции, запуск службы или health-check. Отметьте пользователя, от которого шла установка, и его домашний каталог. Если ошибка содержит путь, начните с него.

Проверьте файловую систему пути командой df -h <путь>. Она покажет размер, занятое и доступное пространство именно на нужном разделе. Затем выполните df -i <путь>: свободные байты не помогут, если число доступных inode равно нулю. Наконец, findmnt -T <путь> поможет понять, к какому mount point относится каталог. Эти три проверки разделяют наиболее частые причины.

Шаг 2. Проверьте все точки расхода

Во время установки место требуется не только финальному бинарнику. Архив сначала скачивается, затем распаковывается; временные копии могут кратковременно сосуществовать. PostgreSQL создаёт кластер данных и журналы. Дополнительные sidecar-компоненты и плагины добавляют свои артефакты. После запуска растут логи, база знаний, вложения и резервные копии.

Составьте таблицу: путь, файловая система, доступные гигабайты, доступные inode, владелец и назначение. Минимальный список включает домашний каталог пользователя установки, /tmp или настроенный временный каталог, путь данных PostgreSQL, каталог журналов и будущий каталог резервных копий. Если эти пути находятся на разных разделах, измерьте каждый отдельно.

Не переносите в расчёт цифру из чужого примера как универсальный минимум. Реальный запас зависит от набора модулей, объёма документов, числа вложений, политики хранения, способа резервного копирования и ожидаемой нагрузки. Актуальные системные требования опубликованы в документации; перед запуском их нужно сверить ещё раз.

Шаг 3. Найдите потребителя, не разрушая данные

Для верхнего уровня каталога удобно использовать du -xhd1 <каталог>: ключ -x не уходит на другие файловые системы, а глубина один даёт обзор без огромного вывода. Сортируйте результат и затем углубляйтесь только в крупные ветки. Для журналов сначала смотрите штатные команды ротации и journalctl --disk-usage, а не удаляйте файлы из /var/log вручную.

Особая осторожность нужна с каталогом PostgreSQL. Удаление неизвестного файла внутри data directory может привести к потере или несогласованности базы. Если база занимает много места, выясните причину штатными SQL-запросами и проверьте резервную копию. Так же нельзя удалять активный release-каталог или пользовательские данные только потому, что они крупные.

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

Шаг 4. Освобождайте место обратимо

Начните с того, что можно восстановить: устаревшие кэши пакетов, подтверждённые временные файлы, старые диагностические архивы и журналы, уже закрытые политикой retention. Перед удалением проверьте владельца, дату и наличие ссылок. Для важного содержимого предпочтительнее сначала перемещение на другой проверенный том и контрольная проверка, а не немедленное уничтожение.

После каждого действия повторите df -h, df -i и измерение нужного каталога. Это не формальность: крупный удалённый файл может оставаться открытым процессом и не освобождать место до перезапуска этого процесса. Команда lsof +L1 помогает увидеть удалённые, но всё ещё открытые файлы. Перезапускайте только понятную службу и только в согласованное окно.

Шаг 5. Повторите установку с контрольными точками

Когда причина устранена, не считайте задачу закрытой. Повторите установку один раз, сохраните журнал и отметьте прохождение этапов. После запуска проверьте состояние systemd-службы, health/readiness endpoint, подключение к PostgreSQL и свободное место. Установка, завершившаяся без ошибки, ещё не доказывает готовность к production: нужны TLS, резервные копии, восстановление, мониторинг, права доступа и тестовый сценарий запроса.

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

Чек-лист перед повторным запуском

• Записана точная ошибка и этап установки.
• Проверены df -h и df -i для каждого рабочего пути.
• Через findmnt подтверждены реальные точки монтирования.
• Найдены крупные каталоги без удаления данных вслепую.
• Каталог PostgreSQL не менялся вручную.
• Учтены временные файлы, плагины, знания, вложения и бэкапы.
• После очистки измерения повторены.
• Есть запас на распаковку и дальнейший рост.
• После запуска проверяются служба, health-check и база.
• Production readiness принимается отдельным чек-листом.

После запуска наблюдайте динамику

Разовая фотография диска нужна для допуска к установке, но эксплуатацию защищает тренд. Запишите базовый объём сразу после запуска, затем измеряйте рост базы, вложений, индекса знаний, журналов и резервных копий через одинаковые интервалы. Для каждого тома задайте предупреждающий и аварийный порог, владельца реакции и безопасную процедуру освобождения места. Порог должен оставлять время на расследование, а не срабатывать за минуту до остановки.

Проверьте ротацию журналов и срок хранения бэкапов на тестовой среде. Смоделируйте заполнение до предупреждающего уровня и убедитесь, что алерт действительно доходит ответственному. Если объём растёт быстрее прогноза, сначала определите источник: новые документы, крупные вложения, зависшая очередь или неверная retention-политика. Capacity planning считается завершённым, когда команда знает скорость роста, время до порога и действие, которое не разрушает рабочие данные.

Источники и границы

Официальные материалы: системные требования, установка и введение в архитектуру. Точные требования могут меняться вместе с релизом и выбранными модулями; перед установкой сверяйте текущую документацию и публичный changelog. Эта статья объясняет диагностический порядок, но не заменяет планирование ёмкости и резервного восстановления для вашей нагрузки.

Если хотите оценить self-hosted-путь, начните с таблицы файловых систем и требований, а уже затем запускайте персональную команду установки.