Files
obsidian-vault/family/tech/t610-hang-investigation.md
T

198 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "🔴 t610: зависания — диагностика (незакрыто)"
aliases: [t610 hang, t610 зависание, t610 freeze, RCU stall investigation, MemTotal деградация]
tags: [family, tech, smarthome, t610, incident]
updated: 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:4109:43.
**Факты о моменте смерти (из читаемого после ребута):**
| Наблюдение | Значение | Откуда |
|---|---|---|
| Журнал оборван на | `07:2907: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 зафиксирована цифра **другого** аппарата/состояния
>
> **Проверка (только чтение, не запущена):**
> ```bash
> 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:3007: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:11721189` объявлены **template-сенсоры БЕЗ `trigger:`**:
```yaml
- 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 |