---
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: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 зафиксирована цифра **другого** аппарата/состояния
>
> **Проверка (только чтение, не запущена):**
> ```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: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:`**:
   ```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 |