Направление про кассовую проверку маркированных товаров. Машина с этим модулем стоит на площадке
«Победа-16» (сеть 10.63.2.0/24).
ЛМ ЧЗ (Локальный Модуль «Честного Знака», продукт называется Regime, написан на Erlang) —
проверяет коды маркировки прямо на кассе, офлайн. ЕСП/ЕСМ — товароучётная система, которая
обращается к этому модулю при продаже.
Цепочка запуска: ЕСП → служебные процессы товароучётной системы → запускают Regime (сам движок
Erlang) → тот поднимает HTTP на локальном порту 5995.
Модуль общается только с локальной машиной (порт слушается на 127.0.0.1) — проверка статуса:
запрос к модулю должен вернуть {"status": "ready"}. Статус not_configured — модуль поднялся,
но ещё не был инициализирован токеном из личного кабинета «Честного знака» — это нормальное
промежуточное состояние, не поломка.
ЛМ отвечает только за кассовую проверку кодов «здесь и сейчас». Документарная часть маркировки —
приёмка товара по электронному документообороту и передача сведений в государственную систему
маркировки — это уже СБИС, см. соответствующий раздел. Ломаются они независимо: если «товар не
продаётся» на кассе — искать проблему в ЛМ; если «товар не оприходован» или «не подтверждена
приёмка» — искать проблему в ЭДО.
Симптом: касса не видела модуль, порт не слушался, сам движок Erlang не был запущен —
работал только вспомогательный процесс-контроллер.
Причина: автоматическое обновление модуля остановило нужные фоновые службы (тем способом,
который отправляет сигнал прерывания процессу), но после установки обновления не подняло их
обратно. Формальная ошибка в логе про повреждённые данные была не причиной, а следствием того,
что процесс, писавший в базу, оборвали на середине операции.
Как это опознать по логам: в логах служб виден характерный управляющий символ (Ctrl+C) в
момент остановки — если открывать такие логи стандартной командой Windows, консоль сама
переспросит про завершение пакетного задания. Это верный признак, что службу остановили
принудительно извне, а не она упала сама.
Дополнительная тонкость запуска: сами командные файлы движка — это не полноценные службы
Windows, они просто запускают процесс в переднем плане. Службами их делает отдельная
вспомогательная утилита-обёртка. В этих командных файлах также обнаружен мелкий, но чувствительный
баг: смена рабочего каталога в скрипте написана без ключа, который позволяет менять каталог между
разными дисками — из-за этого запуск, инициированный не с того диска, будет неизменно проваливаться
с ошибкой «не удаётся найти указанный путь».
Восстановление: службы были пересозданы вручную той же вспомогательной утилитой, с явным
указанием рабочего каталога и файлов для вывода логов, с обязательным порядком запуска — сначала
служба базы, и только через паузу после неё — сама служба модуля.
Результат: после восстановления служб модуль поднялся сам, без необходимости в повторной
инициализации — конфигурация и токен сохранялись в базе данных модуля всё это время. Синхронизация
с центральной системой маркировки догналась автоматически.
Риск на будущее: поскольку восстановленные службы были созданы вручную, официальный
установщик модуля о них не знает. При следующем автоматическом обновлении есть риск повторения
той же ситуации — стоит проверять работоспособность модуля сразу после каждого автообновления.
Есть старый, отдельно стоящий на другой машине экземпляр модуля, который обслуживает
действующую работающую кассу — его трогать нельзя ни при каких обстоятельствах.