[2026-10-27] eagle: family/how-to/arr-stack-taiga.md personal/tech/flaresolverr-taiga.md

family/how-to/arr-stack-taiga.md

@@ -104,6 +104,8 @@ proxy + flaresolverr = [1,2]
 
 Подробности: [[personal/tech/flaresolverr-taiga]].
 
+Повторный сбой 2026-10-26 UTC: реальные отказы RuTracker сопровождались локальной ошибкой Prowlarr `database is locked`; подобные блокировки затрагивали и другие индексаторы, затем Lidarr. Отдельно исправлен watchdog FlareSolverr: признак входа теперь проверяется в HTML после разбора JSON, временная ошибка запроса не сбрасывает рабочую сессию. Проверено: 50 результатов реального поиска, успешный одиночный тест RuTracker в Lidarr, после `CheckHealth` предупреждение о недоступности индексаторов исчезло. Высокое ожидание дискового I/O и блокировки SQLite требуют отдельного разбора; исправление watchdog их не устраняет.
+
 ## Перезапуск и приёмка
 
 ```bash

personal/tech/flaresolverr-taiga.md

@@ -159,7 +159,30 @@ ssh truenas_admin@mallexxx.duckdns.org \
 
 ## Восстановление quarantine
 
-Если Prowlarr показывает старый `IndexerStatus`, сначала сделать backup SQLite. Остановить только Prowlarr, удалить только записи `IndexerStatus`, проверить `PRAGMA quick_check`, запустить и выполнить реальный search. Не удалять `prowlarr.db` и не считать health единственным тестом.
+При старом предупреждении сначала подтвердить реальный search, выполнить одиночный штатный тест соответствующего индексатора и обновить health. Для Lidarr этот путь проверен 2026-10-26: RuTracker test + `CheckHealth` сняли предупреждение без редактирования БД. При API-тестировании использовать действующие секреты, а не маскированные значения из GET. Ручная очистка `IndexerStatus` — резервный способ только при неработающем штатном восстановлении: backup SQLite, остановка только затронутого сервиса, изменение только нужного статуса, `PRAGMA quick_check`, запуск и реальный search. Не удалять всю БД и не считать health единственным тестом.
+
+## Повторный сбой 2026-10-26 UTC / 2026-10-27 Бишкек
+
+Проверено на Taiga; различать два независимых дефекта.
+
+1. **Фактические отказы поиска:** Prowlarr писал `SQLiteException Busy (5): database is locked`. У RuTracker ошибки зафиксированы в 16:08:13 UTC и 17:20:59 UTC, в том числе в `GetCookies → ProviderStatusRepository.FindByProviderId`, до обращения к трекеру. Аналогичные ошибки были у Kinozal, NoNaMeClub и RuTor. Позже такие же блокировки продолжались в Lidarr. Это не доказательство потери авторизации RuTracker.
+2. **Ошибка watchdog:** старый скрипт искал `id="logged-in-username"` через grep в сыром JSON FlareSolverr. Кавычки HTML в JSON экранированы, поэтому рабочая авторизация ошибочно считалась потерянной и session пересоздавалась каждые пять минут. На одной живой сессии подтверждено: parsed HTML logged-in=true, старый grep=false.
+
+Исправлен `/mnt/RED_2TB/docker/arr/flaresolverr-entrypoint.sh`: сначала разбирается JSON, затем проверяется HTML. Повторный login выполняется при явно обнаруженной форме входа; ошибки транспорта, challenge и некорректный ответ считаются неопределённым состоянием и не уничтожают действующую сессию. Таймаут проверки согласован с `BROWSER_TIMEOUT=180000`: 180 секунд внутри FlareSolverr и 240 секунд у curl. Смена egress-IP по-прежнему вызывает восстановление.
+
+Backup исходного скрипта:
+`/mnt/RED_2TB/docker/arr/flaresolverr-entrypoint.sh.before-json-auth-fix-20261026T175021Z`.
+Перезапущен только FlareSolverr; SQLite вручную не редактировалась.
+
+Приёмка:
+- синтаксис shell и пять проверок классификатора ответа прошли;
+- после перезапуска и очередного пятиминутного цикла вход сохранился, HTTP 200, ложных refresh в логах нет;
+- реальный поиск Prowlarr по RuTracker: HTTP 200, 50 результатов за 17 секунд;
+- одиночный штатный тест RuTracker в Lidarr прошёл;
+- после `CheckHealth` предупреждение о недоступных индексаторах исчезло; осталось только уведомление об обновлении Lidarr;
+- поисковые проверки не запускали новые скачивания.
+
+Ограничение: причина локальных блокировок SQLite не устранена этим изменением. На NAS измерено `/proc/pressure/io`: some около 66–70%, full около 50–54%; ZFS pool ONLINE без ошибок, первый mirror заполнен почти полностью (1.79 TiB занято, 27 GiB свободно), новый mirror почти пуст. Это подтверждает высокое ожидание I/O и неравномерное размещение данных, но не доказывает единственную причину блокировки. Настройки ZFS, маршрутизация и мониторинг музыкальной библиотеки не менялись.
 
 ## Итоговый рабочий результат