Глубокий анализ логов загрузки и отказа системы

Дата анализа: 2026-02-10
Система: Ubuntu 24.04, ядро 6.14.0-37-generic (хост Denkart)
Контекст: Наблюдался отказ системы; выполнено восстановление.

1. Хронология загрузок (10 февраля 2026)

Загрузка Boot ID Начало Конец Длительность Примечание
-3 19655a8a… 00:09:11 MSK 00:33:27 MSK ~24 мин —
-2 ec91383b… 00:33:58 MSK 00:50:49 MSK ~17 мин Конец сессии: диск уже переполнен
-1 93075052… 00:51:20 MSK 00:55:56 MSK ~4,5 мин Отказ: загрузка при заполненном диске
0 (текущая) afabe41b… 03:01:28 MSK — — Восстановление после освобождения места

2. Установленная причина отказа

2.1 Основная причина: переполнение корневого раздела

  • Симптом в логах: массовые сообщения rsyslog:
  • file '/var/log/syslog' write error … OS error: No space left on device
  • Когда проявилось:
  • В загрузке -2: первые записи «No space left on device» в 00:50:49 (в конце сессии).
  • В загрузке -1: та же ошибка с 00:51:24 (через ~4 с после старта ядра) и до конца загрузки (00:55:56).

Вывод: К моменту перезагрузки (перехода к загрузке -1) диск уже был заполнен. Система загрузилась при отсутствии свободного места на корневом разделе; rsyslog не мог писать в /var/log/syslog, что привело к массовой потере логов и нестабильной работе.

2.2 Текущее состояние после восстановления

  • Корневой раздел: /dev/sdb2 — 233 G, занято 105 G, свободно 124 G (~46% занято).
  • Inode: использовано ~4%, переполнения inode нет.
  • Сервисы: упавших unit’ов нет (systemctl --failed — 0 loaded units).
  • Загрузка в момент анализа ещё не была завершена (Bootup is not yet finished); среди самых долгих при старте: backup-postgres.service (~13.7 с), bbb-cleanup-recordings.service (~8.4 с), snap.lxd.activate.service (~8 с).

3. Анализ логов по загрузкам

3.1 Загрузка -2 (00:33–00:50)

  • В конце сессии (00:50:49) — многократные ошибки rsyslog: No space left on device при записи в /var/log/syslog.
  • То есть переполнение диска произошло до перезагрузки (во время работы этой загрузки или предыдущей).

3.2 Загрузка -1 (00:51–00:55) — отказная

  • Старт ядра: 00:51:20 (Linux 6.14.0-37-generic, ASRock B650 PG Lightning, BIOS 3.30).
  • Уже в 00:51:24 — ошибки rsyslog «No space left on device» (диск заполнен с самого начала загрузки).
  • Дополнительно в логах загрузки -1:
  • hub 8-0:1.0: config failed, hub doesn't have any ports! (err -19) — известная особенность USB/контроллера, не причина отказа.
  • Загрузка -1 длилась около 4,5 минуты и завершилась (далее — восстановление и загрузка 0 в 03:01).

3.3 Текущая загрузка (0, с 03:01)

  • Ошибки уровня err в текущей загрузке — не критичные для работы системы:
  • hub 8-0:1.0: config failed, hub doesn't have any ports! (err -19)
  • gkr-pam: unable to locate daemon control file
  • Gdm: on_display_added/removed: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed
  • Failed to start app-gnome-ubuntu-report-on-upgrade-10769.scope
  • Ни одна из них не связана с диском или с причиной прошлого отказа.

4. Что могло занять место на диске

  • Логи и журналы: на момент анализа /var/log — 838 MiB, journal — 507,6 MiB. После очистки при восстановлении объёмы могли быть существенно больше до сброса (в т.ч. старые syslog, journal, backup-логи).
  • Лог бэкапов: /var/log/backup-full-server.log — 52 MiB (текущий размер); при регулярном полном бэкапе без ротации мог сильно разрастаться.
  • Таймеры бэкапов: по отчёту от 2026-02-07 в BOOT-LOG-REPORT.md при загрузке запускались backup-lxd-snapshots.service и backup-postgres.service (с задержкой из-за Persistent=true). Даже с введённым OnBootSec=15min любые последующие срабатывания по расписанию или ручные запуски могут увеличивать использование диска (снапшоты LXD, дампы PostgreSQL, логи).
  • Мониторинг диска: таймер disk-space-monitor.timer активен (проверка каждые 5 минут). Почему пороги не сработали до переполнения, нужно уточнять отдельно (например, очень быстрый рост объёма или каталог вне типичных целей очистки).

5. Связь с предыдущим отчётом (BOOT-LOG-REPORT.md, 2026-02-07)

  • В том отчёте устранены ошибки: backup-postgres.service (неверное имя контейнера), backup-lxd-snapshots.service (exit code из-за ((SUCCESS_COUNT++)) при set -e), замена MemoryLimit= на MemoryMax=, введение OnBootSec=15min для таймеров бэкапов.
  • Текущий отказ не вызван этими старыми ошибками юнитов, а вызван переполнением диска. Исправления из 2026-02-07 по-прежнему актуальны для стабильной загрузки и бэкапов.

6. Рекомендации по предотвращению повторения

6.1 Обязательно

  1. Проверить и при необходимости усилить защиту от переполнения диска:
  2. Убедиться, что disk-space-monitor.timer и disk-space-monitor.service включены и выполняются (уже активны).
  3. Проверить пороги и действия в disk-space-monitor.sh и disk-space-emergency-cleanup.sh (см. docs/operations/disk-space-protection.md).

  4. Убедиться, что в очистку попадают каталоги/файлы, которые реально разрастались (логи бэкапов, journal, старые снапшоты при необходимости).

  5. Ротация и квотирование логов бэкапов:

  6. Настроить logrotate для /var/log/backup-full-server.log и других крупных логов бэкапов (размер/возраст), чтобы они не заполняли диск.

  7. При необходимости ограничить размер journal: в /etc/systemd/journald.conf — SystemMaxUse=, RuntimeMaxUse=.

  8. Резерв свободного места (если ещё не сделано):

  9. Следовать docs/operations/disk-space-protection.md: резерв для корня (например, 2 GB) и при необходимости настройка резерва файловой системы (reserved blocks), чтобы при критической нехватке места оставался минимум для работы и очистки.

6.2 Желательно

  1. Мониторинг и алерты:

  2. Использовать обновлённые алерты Prometheus из раздела «Проактивный мониторинг» в disk-space-protection.md, чтобы получать предупреждение до достижения критического порога.

  3. Регулярный обзор крупных каталогов:

  4. Периодически проверять du по /var, /home, корню, чтобы выявлять неожиданный рост (например, один из бэкапов или логов).

  5. Документирование восстановления:

  6. Кратко зафиксировать, какие действия были выполнены для освобождения места при восстановлении (какие файлы/каталоги удалены или перенесены), чтобы при повторении инцидента процедура была воспроизводимой.

7. Краткая сводка

Пункт Содержание
Причина отказа Переполнение корневого раздела («No space left on device»).
Когда проявилось Конец загрузки -2 (00:50:49); загрузка -1 (00:51–00:55) прошла уже при заполненном диске.
Восстановление Освобождение места на диске и перезагрузка в 03:01 (загрузка 0).
Текущее состояние Свободно ~124 G на корне, упавших сервисов нет, мониторинг диска активен.
Действия Усилить ротацию логов бэкапов, проверить пороги и очистку в disk-space-monitor, зарезервировать минимум свободного места, при необходимости ограничить размер journal.

Документ подготовлен: AI Denkart, технический директор проекта DENKART
Владелец ресурсов: CDTO Dkvark