git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8dfc9d76c59f2daa38d38216f943291a4b6fe136
obsidian-vault/family/tech/t610-hang-investigation.md
T

14 KiB
Raw Blame History

title, aliases, tags, updated
title aliases tags updated
🔴 t610: зависания — диагностика (незакрыто)
t610 hang
t610 зависание
t610 freeze
RCU stall investigation
MemTotal деградация
family
tech
smarthome
t610
incident
2026-09-17

🔴 t610 — зависания: состояние расследования

Статус: ПРИЧИНА НЕ УСТАНОВЛЕНА. Сессия 2026-09-17. Ниже — что проверено фактом, что опровергнуто, и какой единственный вопрос остался невыясненным. Родительская дока: family/how-to/home-automation · §3.1 (RCU stall, закрыто), §3.5 (ограничения аддона), §3.9 (память).

1. Что произошло

Alex перезапустил t610 вручную (сброс питанием) 2026-09-17 ~09:38 +07. Хост поднялся заново; HA Core стартовал ~09:41–09:43.

Факты о моменте смерти (из читаемого после ребута):

Наблюдение Значение Откуда
Журнал оборван на 07:29–07:31 локально, внезапно, без последней строки mtime home-assistant_v2.db = 07:29, -wal = 07:31
БД закрыта чисто? ❌ НЕТ — The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly ha core logs
Незакрытая сессия Ended unfinished session (id=36 from 2026-09-16 05:46:10) тam же
Аптайм до ребута ≈ 26 ч (сессия с 2026-09-16 05:46 → смерть 07:31) тam же

🔴 Ключевой вывод: процесс не завершился сам — БД не закрыта, журнал обрывается на полуслове. Система умерла без возможности корректного shutdown (RCU stall / hard freeze), а не упала по исключению.

2. ⛔ Логи прошлого запуска — ДОСТУПА НЕТ (ограничение подтверждено)

Проверено повторно 2026-09-17, подтверждает family/how-to/home-automation §3.5:

Источник Результат
ha core logs только 12 строк текущего контейнера (s6-rc boot)
/config/home-assistant.log.fault 0 байт
/config/home-assistant.log не существует
journalctl -b -1 пусто; /var/log/journal не существует
ha supervisor logs только текущая загрузка (100 строк)

📌 Следствие, которое надо принять: после каждого жёсткого зависания следы стираются. Диагноз надо ставить до перезагрузки, либо поднять ретенцию (см. §6). Это не «не нашёл» — это структурное свойство HAOS (журнал в RAM).

Что спасло расследование: журнал событий (логбук) лежит в /config/home-assistant_v2.db и пережил ребут. Именно из него реконструирован профиль нагрузки до смерти.

3. Что проверено ФАКТОМ (данные после ребута)

3.1. Хост видит 1.44 ГБ, не 3.31 ГБ — расхождение с докой

MemTotal:     1475788 kB   ← 1.44 ГБ  ← ЖИВОЙ ФАКТ 2026-09-17
MemFree:        18620 kB   ← 18 МБ
MemAvailable:  758304 kB   ← 740 МБ
Cached:        837992 kB
SwapTotal:    1024 МБ, used 0

🔴 ЭТО ПРОТИВОРЕЧИТ family/how-to/home-automation §3.9, где зафиксировано MemTotal: 3 470 792 kB = 3.31 ГиБ (проверено 2026-09-15).

Расхождение: 3.31 ГБ → 1.44 ГБ. Это НЕ объясняется округлением.

Гипотезы, которые осталось проверить (ни одна не подтверждена):

  1. Планка памяти деградировала/вынута/не детектится со времени проверки 2026-09-15
  2. Сменилась конфигурация UMA-фреймбуфера в BIOS
  3. В §3.9 зафиксирована цифра другого аппарата/состояния

Проверка (только чтение, не запущена):

ssh root@192.168.2.176 'dmesg | grep -iE "e820|BIOS-provided|Memory:"'
ssh root@192.168.2.176 'dmidecode -t memory 2>/dev/null | grep -E "Size|Locator"'

⚠️ НЕ читать MemFree как «сколько всего памяти» (питфоллы 44–45 в родительской доке). Alex видел «1 ГБ» на экране — вероятнее всего это MemFree в состоянии с большим файловым кэшем, но живой MemTotal 1.44 ГБ — это уже другой разговор, не округление.

3.2. Память по контейнерам (норма из доки, для сравнения)

Node-RED 197 МБ · HA Core 212 МБ · Supervisor 77 МБ · modbus-bridge 20 МБ · Mosquitto 19 МБ · mbusd 0.8 МБ. Большинство аддонов сейчас stopped (nodered, z2m).

3.3. Состояние HA после подъёма

Метрика Значение
Сущностей 310
Автоматизаций 23 (22 on, 1 off намеренно)
Выключена намеренно automation.ventilation_automation_on (last_triggered 2026-03-12)
unavailable (Zigbee) 13 (блок kitchen_hood, office_table_light_switch, bedroom/kitchen light, shower_2_presence_sensor, dushevaia_floor_temperature) — ZHA ещё догружается после холодного старта
HA / HAOS 2026.9.2 / HAOS 18.2
Аддоны core_ssh 10.4.0 (апдейт до 10.5.0 доступен), core_mosquitto, local_mbusd, local_modbus-bridge, local_ustreamer — started; nodered, zigbee2mqtt — stopped (как и должно)

✅ Холодный старт медленный, но штатный: внешний https://mallexxx.duckdns.org начал отвечать только через ~1 минуту после запуска Core. http://192.168.2.176:8123 из LAN даёт curl exit 7 (недоступен) — не поломка, ходить только через duckdns (питфолл 1).

3.4. Профиль нагрузки перед смертью (из логбука, пережил ребут)

Замер на окне 06:30–07:40 локально: 1763 записи логбука. Доминировали template-сводки:

kids_summary / dining_summary / dining_air_summary / bedroom_summary
→ каждые ~5–10 секунд, круглосуточно

Механизм (установлен):

  1. sensor.kids_co2 / bedroom_co2 / dining_co2 — platform: mqtt, приходят от modbus-bridge (сниффер ZONT-шины, ha.url: http://localhost:8123, poll_interval: 15); значение меняется каждый тик (CO2 живой: 1677 → 1592 ppm за 9 мин).
  2. В /config/configuration.yaml:1172–1189 объявлены template-сенсоры БЕЗ trigger:: 
    - name: kids_summary
  state: "{{ states('sensor.kids_temperature')|round(0)|int }}° {{ states('sensor.kids_co2')|int }}ppm"
    Без trigger такой сенсор пересчитывается на любой state_changed в системе, не только на своих источниках.
  3. Замер живьём: sensor.kids_summary — 53 изменения за 9 минут (каждые ~5 с).
  4. recorder: блока в configuration.yaml НЕТ ВООБЩЕ → запись всего подряд, дефолт 10 дней, без exclude.

⚠️ Статус версии: ОПРОВЕРГНУТА как причина (Alex, 2026-09-17). «Это обычная работа HA пересчитывать датчики» — верно. Пересчёт шаблонов сам по себе не вешает систему. Нагрузка на БД реальна (77 МБ БД + WAL 4.4 МБ + поток записи), но связь с зависанием НЕ доказана. Записано как «контекст нагрузки», а не как причина.

4. ⛔ Что ОПРОВЕРГНУТО (не повторять)

Версия Почему неверна
«Template-сенсоры без trigger вешают HA» Alex: это штатная работа HA. Пересчёт — норма, не причина
«iGPU/UMA вырезал ~607 МБ из 2 ГБ» Строилось на MemTotal 1.44 ГБ как «2 ГБ минус фреймбуфер». При физически 1 ГБ вырезать нечего
«MemFree 1 ГБ = кончилась память» Питфоллы 44–45: MemFree падает из-за файлового кэша. Верные метрики — MemTotal + MemAvailable
«Логи есть, надо просто посмотреть внимательнее» Их нет физически (§2). Проверено 5 источников

5. ❓ ЕДИНСТВЕННЫЙ НЕЗАКРЫТЫЙ ВОПРОС

Развилка, которая разводит два совершенно разных направления:

Если… То диагноз Куда копать
Вешается через примерно одинаковый аптайм (~N часов) Софт накапливает: утечка в процессе, рост БД, исчерпание ресурса recorder + exclude, профилирование памяти по контейнерам во времени
Вешается хаотично Железо: питание (блок/USB 500 мА), температура, HDD 5400 rpm, деградация планки RAM k10temp, pressure/io, dmesg | grep -i usb, dmidecode

Ответ Alex на этот вопрос — НЕ ПОЛУЧЕН. Это следующее, что нужно выяснить.

Дополнительные вопросы, ответы на которые нужны:

  • В момент зависания хост отвечал вообще (веб открывался, но тупил) или пропал полностью?
  • Это какой по счёту раз? Есть ли даты предыдущих зависаний?

6. 📋 Предложение (НЕ одобрено, НЕ внедрено)

⛔ Ничего из этого не применено. План-first: ждёт апрува Alex. Правки configuration.yaml — только через патч + показ диффа → апрув → заливка → проверка Alex'ом.

  1. Сбор метрик, переживающий перезагрузку — раз в минуту писать в файл на /mnt/data: MemTotal/MemAvailable/MemFree, load, pressure/io+pressure/memory, k10temp, размер БД+WAL, аптайм. Это то, что даст версию к следующему зависанию — сейчас каждый инцидент стирает свои следы.
  2. recorder: с exclude — исключить sensor.*_summary, at2_*_summary, update.*, button.*_identify, event.*. Снижает нагрузку на БД. Не «фикс зависания» — отдельное улучшение.
  3. Включить watchdog local_ustreamer — единственный аддон без watchdog (§3.7 родительской доки).
  4. Обновить core_ssh 10.4.0 → 10.5.0.

📌 Версия «что именно вешает» появится только после п.1. Без ретенции расследование упирается в §2 и превращается в перебор гипотез.

7. Питфоллы сессии (дополнение к родительской доке)

# Питфолл Обход
53 🔴 Журнал прошлого запуска недоступен ПОСЛЕ жёсткого зависания — подтверждено повторно, 5 источников пусты Ставить диагноз ДО ребута, либо ретенция (§6.1). Логбук в home-assistant_v2.db переживает ребут — использовать его
54 ⚠️ ha core logs показывает только текущий контейнер (12 строк s6-rc), не историю Не искать «старые строки» — их нет
55 ⚠️ MemTotal может расходиться с докой — живой факт 1.44 ГБ против зафиксированных 3.31 ГБ (§3.9 родительской доки) Всегда перемерять head -3 /proc/meminfo при разборе инцидента, не полагаться на записанное
56 🔴 http://192.168.2.176:8123 из LAN → curl exit 7, хоть хост жив Единственный путь к API — https://mallexxx.duckdns.org. Совпадает с питфоллом 1
57 ⚠️ После холодного старта ZHA догружается: часть сущностей минуты висит unavailable Не спешить с выводом «устройства отвалились» — перемерить через 2–3 мин. Первый снимок дал 75 сущностей, полный — 310
Reference in New Issue View Git Blame Copy Permalink