Просмотреть исходный

Прежде чем применять настройки - внимательно читаем. От этого зависит работоспособность системы

Для абонбащзы свыше 30 тыс абонентов, настоятельно рекомендуется перейти на системный юнит unisorm

11.4. UNISORM КАК SYSTEMD-СЕРВИС

Unisorm можно запускать двумя способами: через billd (как раньше) или отдельным systemd-сервисом unisorm.service. Второй способ быстрее: фазы сбора (абоненты, адреса, идентификация, платежи) выполняются параллельно, а не последовательно.

Логика работы модуля при этом НЕ меняется: тот же Core.pm, те же параметры из таблицы config, та же проверка изменений по хешам, то же формирование файлов и выгрузка. Меняется только способ запуска.

Установка

Выполнить от root:

bash <каталог установки>/misc/unisorm/install_unisorm_service.sh

Пример для стандартной установки:

bash /usr/acp/misc/unisorm/install_unisorm_service.sh

Если каталог нестандартный, указать его явно:

bash /opt/mybilling/misc/unisorm/install_unisorm_service.sh /opt/mybilling

Установщик сам определяет каталог установки по наличию cgi-bin/index.cgi, подставляет реальный путь в юнит, записывает параметры в таблицу config базы данных (в config.pl ничего не пишется), устанавливает юнит в /etc/systemd/system/unisorm.service, выполняет daemon-reload, enable и restart, затем проверяет, что сервис активен.

Повторный запуск установщика безопасен: он переустанавливает юнит и перезапускает сервис.

Параметры, которые записывает установщик

UNISORM_SYSTEMD_MODE = 1 — Unisorm работает отдельным сервисом, billd перестаёт запускать сбор.
UNISORM_SYSTEMD_TIMEOUT = 7200 — максимальное время одной фазы в секундах.

Устаревший параметр UNISORM_SYSTEMD_WORKERS удаляется, если он был.

Проверка работы

systemctl status unisorm
journalctl -u unisorm -f

В логе должны появиться строки: Unisorm runner started: mode=loop workers=4 prefix=<каталог установки>, затем phases: abonent, address, ident, payments (cpu cores: N) и четыре строки worker '...' spawned (pid=...).

Настройка в интерфейсе

Настройка → Системные настройки → Настройки ядра → Unisorm, секция «Системный сервис Unisorm (systemd)».

Флаг «Unisorm работает отдельным сервисом unisorm.service» управляет и billd, и самим сервисом. Если он включён — сбор ведёт сервис, billd не запускает Unisorm. Если выключен — сервис ничего не делает (воркеры остановлены, процессор не нагружает), а сбор ведёт billd. Флаг перечитывается каждые 10 секунд, поэтому переключение применяется без ручного перезапуска.

Остальные параметры секции: таймаут прогона, пауза между циклами (по умолчанию 15 секунд, снижает нагрузку на процессор), расписание выгрузки файлов в виде cron-записи (например, */10 * * * * — каждые 10 минут) и логирование действий модуля в файл <каталог установки>/var/log/sorm/unisorm.log.

При включённом флаге поля «Частота сбора данных по абонентам и сервисам» и «Сколько секунд ждать освобождения unisorm.lock» не используются.

Ручной запуск

Чтобы запустить Unisorm вручную (например, для отладки), сначала выключите флаг UNISORM_SYSTEMD_MODE в интерфейсе и дождитесь, пока сервис уйдёт в простой (до 10 секунд, в логе будет «service goes IDLE»). Затем запускайте:

<каталог установки>/libexec/billd unisorm START=1 DEBUG=1

После отладки включите флаг обратно — сервис поднимется сам.

Про PID: юнит имеет Type=simple и не задаёт PIDFile, это нормально — systemd сам знает PID главного процесса. Посмотреть его можно командой systemctl show unisorm -p MainPID --value.

Про блокировку: файл unisorm.lock берёт billd при запуске Unisorm, сам сервис этот лок не берёт. Поэтому одновременный ручной запуск при включённом флаге привёл бы к двум параллельным прогонам — флаг нужно выключать перед ручным запуском.

Автоперезапуск

Сервис перезапускается автоматически при изменении кода на диске (billd пишет маркер CODE_MTIME, сервис проверяет его каждые 30 секунд) и при изменении параметров модуля (сервис собирает список параметров из исходников Core.pm и Exporter/*.pm и каждые 10 секунд сравнивает их значения с сохранённым снимком).

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

Удаление сервиса

Порядок важен: сначала выключить флаг UNISORM_SYSTEMD_MODE в интерфейсе (это вернёт запуск сбора в billd), затем остановить и удалить сервис:

systemctl stop unisorm
systemctl disable unisorm
rm -f /etc/systemd/system/unisorm.service
systemctl daemon-reload

Если удалить сервис, не выключив флаг, сбор данных остановится полностью: billd не будет запускать Unisorm (флаг включён), а сервиса уже не будет.

Описания настройки в вебинтерфейсе

АСР Казна-39 > Системный юнит unisorm > image-2026-10-24_10-10-42.png

Параметр	Описание
Unisorm работает отдельным сервисом unisorm.service	Включайте, только если Unisorm установлен как отдельный systemd-сервис (unisorm.service). В этом режиме ВСЮ работу выполняет сервис: сбор данных, формирование файлов выгрузки, отправку файлов на FTP/SFTP по расписанию, подготовку справочников и аварийные команды. billd при этом не запускает собственный сбор (START) — иначе два процесса конкурируют за блокировку unisorm.lock и мешают друг другу. ВАЖНО: при включении этого флага поля «Частота сбора данных по абонентам и сервисам» (BILLD_UNISORM_AUTOSTART_INTERVAL) и «Сколько секунд ждать освобождения unisorm.lock» (UNISORM_LOCK_WAIT_TIMEOUT) не используются — сбор ведёт сервис по своим параметрам. Расписание отправки файлов в этом режиме задаётся параметром «Расписание выгрузки файлов» (UNISORM_SYSTEMD_SEND_FTP_CRON) на этой же вкладке. ВАЖНО: если вы ВЫКЛЮЧАЕТЕ этот флаг, сервис unisorm.service автоматически переходит в режим простоя: останавливает воркеров, ничего не собирает и не нагружает процессор, а сбор данных снова выполняет billd. Удалять сервис при этом НЕ нужно — он остаётся установленным и снова включится, как только вы вернёте флаг. Если параметр выключен или отсутствует, поведение полностью прежнее.
Максимальное время одной фазы, секунды	Ограничивает время выполнения одной фазы сбора. Первичное заполнение на крупных инсталляциях (десятки тысяч абонентов) занимает много времени, поэтому по умолчанию 7200 секунд (2 часа). Значение меньше 60 секунд автоматически поднимается до 60. Параметр используется ТОЛЬКО системным сервисом. Подбирается исходя из абонбазы! По умолчанию выставлено на 250 тыс абонентов
Сколько секунд отдыхать после выгрузки, перед новым сбором	Задаёт паузу между циклами работы сервиса unisorm.service. Цикл устроен так: все фазы сбора (абоненты, адреса, идентификация, платежи) выполняются параллельно, затем запускается финальная фаза (формирование файлов выгрузки), после чего сервис выдерживает паузу и начинает новый цикл. Пауза нужна, чтобы снизить нагрузку на процессор: без неё сервис занят сбором 100% времени и постоянно нагружает CPU. Во время паузы воркеры спят и процессор свободен, при этом мастер продолжает проверять аварийные команды и расписание выгрузки файлов (SEND_FTP) — они срабатывают сразу, не дожидаясь конца паузы. Изменения данных, сделанные во время паузы, будут обнаружены на следующем цикле, поэтому задержка обнаружения изменений не превышает значения этого параметра. Значение 0 отключает паузу — сервис будет работать непрерывно с максимальной нагрузкой на CPU. Параметр используется ТОЛЬКО системным сервисом; при работе через billd он не применяется.
Cron-запись: как часто отправлять подготовленные файлы на FTP/SFTP	Задаёт расписание, по которому сервис unisorm.service отправляет уже подготовленные файлы на FTP/SFTP (режим SEND_FTP). В systemd-режиме billd не запускает Unisorm, поэтому отправку выполняет сам сервис — без этого параметра файлы формируются локально, но никуда не уходят. Формат — стандартная cron-запись из 5 полей (минута, час, день месяца, месяц, день недели) или из 6 полей (с секундами в начале). Поддерживаются , списки (1,3,5), диапазоны (1-5) и шаги (/10, 1-30/5). Примеры: /10 * * * — каждые 10 минут; 0 3 * * * — ежедневно в 03:00; 0 /2 * * — каждые 2 часа. Если поле пустое, отправка по расписанию не выполняется. Отправка запускается только когда не идёт финальная фаза, чтобы не отправить недописанные файлы. Параметр используется ТОЛЬКО системным сервисом; при работе через billd расписание задаётся параметром BILLD_UNISORM_SEND_FTP_CRON.
Писать действия модуля Unisorm в файл журнала	Включает запись всех действий модуля Unisorm в отдельный файл журнала, чтобы можно было разобрать ошибки постфактум. Файл располагается в каталоге <каталог установки>/var/log/sorm/unisorm.log — путь вычисляется от каталога установки системы (переменная $base_dir из config.pl), поэтому корректен при установке биллинга в любую папку. Каталог log/sorm создаётся автоматически при первом включении. В файл попадают те же строки, что и в стандартный вывод (journald при работе системным сервисом или консоль billd при запуске через billd), поэтому включение логирования не меняет поведение системы. Запись ведётся в режиме дозаписи с немедленным сбросом на диск, поэтому при аварийном завершении процесса данные не теряются. Один общий файл используется всеми процессами модуля (мастер, воркеры фаз, финальная фаза). Файл не ротируется автоматически — при необходимости ограничивайте его размер средствами logrotate. Если параметр выключен, файл не создаётся и каталог не создаётся.