Завершение службы шлюза: проверить сохранение очереди до stop timeout
При штатном перезапуске полевой сборщик хозяйства теряет последние сообщения. Возможно, завершение не успело сохранить очередь или процесс был принудительно остановлен. Проверяйте обработку остановки и фактическую судьбу данных. Исчезновение процесса из списка не подтверждает корректное завершение. Приёмка должна показать, что происходит с собственной тестовой последовательностью при обычном останове и при предусмотренном превышении времени, сохраняя различие между системным событием и прикладной сохранностью.
Установить порядок остановки
Systemd.service задаёт TimeoutStopSec и дальнейшее поведение при незавершённом останове. (systemd — service) Точные действия зависят от конфигурации и версии. Таймер не сохраняет данные за приложение. Сохраните фактический обработчик завершения, доступные стадии и соответствующие результаты. Не назначайте бесконечное ожидание как универсальное решение: оно может скрыть зависание. Длительность выбирается по проектной задаче и подтверждённой работе приложения, а не по одному успешному останову пустого сборщика без очереди данных.
В карте состояния отделите принятые сообщения, очередь в памяти, сохранённую запись и завершение процесса. Для каждого определите доступное подтверждение. Если приложение сообщает «сохранено» до фактического завершения своего хранилища, это ограничение нужно проверить отдельно. Операционная система и носитель имеют собственные гарантии; один unit статус не доказывает долговечность всех записей. Используйте существующий предусмотренный механизм сохранения и не добавляйте произвольные команды синхронизации в production останов без доказанного основания и стендовой проверки.
Сверить последовательность после старта
На стенде подайте собственные различимые сообщения и остановите копию службы штатным способом. Сохраните этапы, затем запустите её и сравните принятые и восстановленные записи. Проверяйте идентичность, а не только количество. Потеря одной записи и повтор другой способны дать одинаковую сумму. Не применяйте рабочие управляющие задания как тест: при восстановлении они могут иметь исполнительный эффект. Тестовая очередь должна быть безопасной и отделённой от реального оборудования и архивного ряда хозяйства.
В отдельном разрешённом опыте смоделируйте задержанное завершение на изолированной среде и наблюдайте исход после установленного ограничения. Укажите, какие данные сохранились, какие остались неизвестными и как приложение сообщает об этом. Не отключайте питание действующего шлюза ради проверки unit таймера: это другой сценарий. После возврата штатного режима подтвердите отсутствие зависшего старого процесса и новый измерительный цикл. Ручное удаление временного файла не должно скрывать неподтверждённую целостность очереди после принудительного завершения тестового сборщика.
Принять сохранённое состояние
В акте сохраните последовательность, stop события и сверку после запуска. Приёмка подтверждает конкретный порядок завершения с известными ограничениями. Для хозяйства это делает перезапуск управляемым: инженер знает, когда очередь действительно восстановлена и что произошло при превышении времени. Успешный stop остаётся системным результатом своего этапа, а сохранность сообщений получает отдельное доказательство. Такой подход помогает отличить потерю в приложении, ограничение процедуры останова и последующий повтор обработки, не подменяя все причины одной общей подписью о перезапуске шлюза.
