OScam lb_savepath: статистика loadbalancer и где хранится

Если ты настраивал OScam с несколькими ридерами, то наверняка сталкивался с ситуацией: перезапустил демон, и балансировщик снова начинает учиться с нуля. Всё потому, что OScam lb_savepath статистика — это не просто один параметр, а связка трёх настроек, без которых накопленные данные ECM живут исключительно в оперативной памяти. Разберём, где физически хранится файл stat, как его правильно настроить и почему всё может идти не так.

Что такое lb_savepath и зачем он нужен

Коротко: lb_savepath — это полный путь к файлу, в котором OScam сохраняет статистику работы loadbalancer. Конкретно — среднее время ответа каждого ридера в разрезе CAID, Provider ID и Service ID. Без этого параметра всё, что балансировщик успел накопить, живёт в RAM и исчезает при первом же перезапуске oscam-демона.

Параметр lb_savepath в секции [global]

Параметр прописывается в секции [global] файла oscam.conf. Выглядит это так:

[global]
lb_mode = 1
lb_save = 100
lb_savepath = /etc/tuxbox/config/oscam/stat

Обрати внимание: указывается полный путь к файлу, не к каталогу. OScam не добавит имя файла автоматически — если написать только каталог, он попытается записать в него как в файл и получит ошибку.

Связь с loadbalancing (lb_mode) и накоплением статистики ECM

Параметр lb_savepath работает только при включённом lb_mode. Если lb_mode = 0 (значение по умолчанию), балансировщик просто выключен, и stat-файл не создаётся вообще, как бы ты ни прописал путь. Нужно явно выставить lb_mode = 1, 2 или 3 — в зависимости от алгоритма балансировки, который тебя устраивает.

Режим 1 — самый простой, выбирает ридер с минимальным средним временем ответа. Режим 2 добавляет учёт нагрузки. Режим 3 — наиболее агрессивный, учитывает время последнего успешного ECM. Для большинства домашних установок с 3–5 ридерами режима 1 достаточно.

Что именно записывается в файл stat

Каждая запись в stat-файле — это строка вида: ридер, CAID, ProvID, SrvID, среднее время ответа (в миллисекундах), количество ECM, время последнего успешного ответа и rc-код. OScam использует эти данные при следующем старте, чтобы не начинать с нуля — сразу знает, какой ридер отвечал быстрее для конкретного канала.

Где OScam хранит статистику по умолчанию

Если lb_savepath не задан, OScam пишет файл с именем stat прямо в каталог конфигурации — тот самый configdir, который определяется флагом -c при запуске демона. Вот тут и начинаются расхождения между платформами.

Путь по умолчанию: <configdir>/stat

На большинстве установок configdir — это то место, где лежит oscam.conf, oscam.server и остальные конфиги. OScam просто дописывает к этому пути имя файла stat. Получается что-то вроде /etc/oscam/stat или /usr/local/etc/oscam/stat.

Как узнать свой configdir (флаг -c при запуске)

Самый надёжный способ — посмотреть на команду запуска процесса:

ps aux | grep oscam

Ищи флаг -c в строке. Например: oscam -c /var/etc/oscam — вот твой configdir. Если флага нет, OScam использует путь, скомпилированный по умолчанию. Узнать его можно через webif: раздел Configuration, в заголовке страницы или в разделе About отображается текущий configdir.

Отличие на ресиверах (Enigma2), роутерах и Linux-серверах

Это то, что многие источники просто игнорируют, и потом люди часами ищут файл не там.

На Enigma2-ресиверах (Vu+, Dreambox, Zgemma и подобных) конфиги OScam чаще всего лежат в /etc/tuxbox/config/oscam/ или /var/etc/oscam/. Соответственно, stat там же. Но многие ресиверы монтируют корневую файловую систему в RAM — то есть /etc может быть tmpfs, и после ребута всё пропадёт.

На роутерах с OpenWrt или Padavan ситуация похожая. Конфиги нередко кладут в /etc/oscam/, но /etc на роутере — это overlayfs поверх squashfs. Запись теоретически работает, но после сброса до заводских настроек улетит всё. Надёжнее хранить stat в /opt/etc/oscam/ (если есть Entware) или на USB.

На обычном Linux-сервере (Debian, Ubuntu, CentOS) путь типа /etc/oscam/stat или /usr/local/etc/oscam/stat работает нормально — файловая система постоянная, права на запись настраиваются стандартно через chown.

Как правильно настроить lb_savepath

Вот рабочий минимум для секции [global], который действительно сохраняет статистику между перезапусками:

Пример секции [global] с lb_savepath

[global]
lb_mode                = 1
lb_save                = 100
lb_savepath            = /etc/oscam/stat
logfile                = /var/log/oscam.log

Три параметра работают вместе: lb_mode включает балансировщик, lb_save говорит, как часто сохранять, lb_savepath указывает куда. Убери любой из трёх — и система либо не собирает статистику, либо не сохраняет её.

Выбор пути: постоянное хранилище vs tmpfs

Вот критический момент, который многие пропускают. Если ты прописал lb_savepath = /tmp/oscam/stat, то формально OScam будет записывать файл. Но /tmp на большинстве систем — это tmpfs, то есть оперативная память. После ребута /tmp очищается, и ты получаешь ровно то, от чего пытался уйти: балансировщик учится заново.

Проверь, что твой путь ведёт в постоянное хранилище. На Linux-сервере — любой путь вне /tmp и /run. На Enigma2 — /etc/tuxbox/config/oscam/ обычно монтируется с флешки ресивера и переживает ребут. Но лучше всё равно проверить: mount | grep tuxbox.

Параметр lb_save (интервал автосохранения)

lb_save — это количество обработанных ECM между автоматическими сохранениями на диск. При значении 100 OScam запишет stat-файл каждые 100 ECM. При значении 0 — не будет сохранять вообще (только при корректной остановке демона через oscam -s или kill -SIGTERM).

Здесь важен баланс. Значение 10 — слишком агрессивно для ресивера с NAND-флешем: частые операции записи ускоряют износ. Значение 500 — уже можно потерять статистику, если демон упадёт аварийно. Для домашнего ресивера 100–200 — разумный компромисс.

Проверка прав на запись

Если OScam запущен не от root (что правильно с точки зрения безопасности), у него должны быть права на запись в каталог stat-файла:

ls -la /etc/oscam/

Владелец каталога должен совпадать с пользователем, от которого работает OScam. Исправить:

chown oscam:oscam /etc/oscam/
chmod 755 /etc/oscam/

Замени oscam:oscam на реального пользователя/группу из твоего systemd unit или init-скрипта.

Как читать и интерпретировать файл статистики

Сырой stat-файл — это текст, но разбирать его руками неудобно. Смотреть статистику лучше через webif.

Структура строк stat-файла (rc, time, ecm count)

Каждая строка выглядит примерно так:

R[имя_ридера] C[CAID] P[ProvID] I[SrvID] T[среднее_время_мс] N[кол-во_ECM] L[время_последнего_ECM] RC[код]

Поле RC — это код результата: 0 означает успех, любое другое значение — ошибка (нет entitlement, timeout и т.д.). Поле T — среднее время ответа в миллисекундах, именно по нему балансировщик выбирает ридер. Поле N — сколько ECM прошло через эту пару ридер+сервис.

Если видишь, что у одного ридера T стабильно в районе 300–400 мс, а у другого скачет от 800 до 2000 — балансировщик правильно будет предпочитать первый.

Просмотр статистики через webif (раздел Loadbalancer)

Webif OScam (порт по умолчанию 8888) показывает ту же информацию в нормальном виде. Раздел Status → Loadbalancer — таблица с ридерами, временами ответа, количеством ECM и кодами результатов. Можно фильтровать по CAID. Это на порядок удобнее, чем читать сырой текстовый файл.

Сброс статистики и принудительное пересохранение

Иногда накопленная статистика устаревает — например, сменил ридер или провайдер. Сбросить можно двумя способами:

• Через webif: в разделе Loadbalancer есть кнопка сброса статистики. Демон не нужно останавливать.
• Вручную: остановить OScam (systemctl stop oscam или /etc/init.d/oscam stop), удалить или обнулить файл stat, запустить заново.

Принудительно записать текущую статистику на диск без перезапуска можно через webif — кнопка Save LB Stats в том же разделе.

Типичные проблемы и их решение

Статистика не сохраняется после перезапуска

Первое, что проверяй: значение lb_mode в [global]. Если lb_mode = 0 или параметр вообще отсутствует — балансировщик выключен, статистика не собирается. Второе: путь в lb_savepath ведёт в tmpfs? Проверь командой df -h /путь/к/stat — если тип файловой системы tmpfs, данные исчезнут при ребуте.

Файл stat не создаётся вообще

Три возможные причины. Первая — lb_mode = 0, уже описано выше. Вторая — нет прав на запись в каталог. Смотри логи OScam на уровне normal или выше — там будет сообщение вроде Cannot open file for writing с указанием пути. Третья — каталог из lb_savepath не существует. OScam не создаёт каталоги автоматически, только файл. Создай каталог руками: mkdir -p /путь/к/каталогу.

Отдельный случай — OScam на Enigma2, запущенный при старте системы до того, как успел примонтироваться USB-диск или сетевой ресурс с нужным путём. В этом случае демон стартует, не находит каталог, и пишет stat куда придётся или не пишет вообще. Решение — добавить задержку старта OScam или проверку монтирования в init-скрипте.

Файл растёт слишком большим

При большом количестве ридеров и каналов stat-файл может разрастись до нескольких мегабайт. Параметр lb_stat_cleanup в секции [global] задаёт количество дней, после которых устаревшие записи удаляются. Например, lb_stat_cleanup = 7 уберёт записи старше недели. По умолчанию значение 0 — очистка не производится.

Для ресиверов с маленькой флешкой (128–256 МБ NAND) это критично. Следи за размером: ls -lh /etc/tuxbox/config/oscam/stat.

Ошибки прав доступа в логах OScam

Включи логирование на уровне normal в oscam.conf:

[global]
logfile   = /var/log/oscam.log
loglevel  = 128

После перезапуска смотри лог. Ошибки записи stat-файла будут явными — OScam не молчит о проблемах с файловой системой. Если пользователь OScam не имеет прав на запись, увидишь Permission denied с полным путём — это сразу указывает, где именно проблема.

Ещё один нетривиальный случай: несколько экземпляров OScam на одной машине с разными конфигами, но одним путём в lb_savepath. Они будут перезаписывать stat-файл друг друга — в итоге статистика окажется смесью данных от разных инстанций и будет бесполезна. Если запускаешь несколько экземпляров, каждому нужен свой уникальный путь к stat-файлу.

И последнее: если OScam после старта игнорирует существующий stat-файл или ругается на него в логах — файл мог повредиться при внезапном отключении питания. В этом случае просто удали его и дай OScam начать с чистого листа. Лечить повреждённый stat-файл вручную нет смысла.