Запуск и остановка терминального ПО

Запускает и останавливает терминальное ПО утилита FS365.Starter (исполняемый файл FS365.Starter.exe).

Последовательность запуска приложений

  1. Служба логирования RedLabel (rlsrvc.exe).

    Местоположение исполняемого файла rlsrvc.exe указано в разделе реестра [HKEY_LOCAL_MACHINE\SOFTWARE\FS365\RedLabel] в параметре InstallDir.

  2. XFS-сервисы ПроАТМ/XFS.

    Признаки того, что на терминале установлен и используется уровень ПроАТМ/XFS:

    1. В реестре в ветке [HKEY_LOCAL_MACHINE\SOFTWARE\XFS\SERVICE_PROVIDERS] перечислены сервис-провайдеры с параметром vendor_name=Systema.

    2. В той же ветке параметр DllName содержит путь к каталогу установки ПроАТМ/XFS.

    3. В каталоге установки ПроАТМ/XFS есть файл install.config.xml.

    Чтобы была возможность строронним XFS-сервисам корректно стартовать, предусмотрена задержка перед запуском Ogre.exe. Она настраивается в параметре OTHER_XFS_SUSPEND_TIME.

    ПроАТМ контролирует фактическую успешность запуска XFS-сервисов ПроАТМ/XFS следующих устройств:

    • Sankyo ICT3K5, ICT3K7;

    • Cryptera INT1217/1218;

    • SZZT ZT59x;

    • Custom TG2480-H, VKP80;

    • Xiamen Cashino CSN-A1K;

    • DORS 210BA;

    • DORS PMU-820;

    • JCM TBV-100;

    • DORS SE1;

    • DORS USB;

    • LG ezCDM-3200;

    • Talaris NMD100;

    • Hitachi HCM HT-3842.

    Механизм работает следующим образом:

    1. FS365.Starter запускает XFS-сервис.

    2. XFS-сервис дожидается, когда соответствующее устройство будет готово к работе и посылает сигнал FS365.Starter о том, что устройство успешно работает.

    3. FS365.Starter обрабатывает полученный сигнал и запускает следующий XFS-сервис. Данные события подробно логируются в RedLabel, например, для XFS-сервиса JCM TBV-100:

      fs365.starter.exe   0   Event синхронизации 'shqPS.CIM.JCM-ID003.exe.has_started_event' открыт успешно
      fs365.starter.exe   0   Сервис 'shqPS.CIM.JCM-ID003.exe' сигнализирует о готовности!
      
    4. После того, как запустились все XFS-сервисы FS365.Starter запускает главный процесс ПроАТМ (Ogre.exe).

    При запуске XFS-сервисов, для которых не работает описанный механизм, FS365.Starter ожидает 10 секунд, после чего считает, что можно запускать следующий XFS-сервис или Ogre.exe.

  3. Агент мониторинга (MonitoringAgent.exe).

    Агент мониторинга запускается, если есть записи в разделе реестра [HKEY_LOCAL_MACHINE\SOFTWARE\FS365\MonitoringAgent].

  4. Главный процесс ПроАТМ (Ogre.exe).

  5. Синхронизатор системного реестра (RegFlusher.exe).

  6. Агент 24/7 (Agent247.exe).

Местоположение исполняемых файлов MonitoringAgent.exe, Ogre.exe, RegFlusher.exe и Agent247.exe указано в параметре OgreInstallDir.

Последовательность остановки приложений

  1. ПроАТМ;

  2. синхронизатор реестра;

  3. агент мониторинга;

  4. агент 24/7;

  5. сервисы ПроАТМ/XFS;

  6. (после задержки в 20 секунд) сервис логирования RedLabel.

Определение порядка запуска сервисов. Пользовательские сервисы

Механизм запуска FS365.Starter позволяет как устанавливать свой порядок запуска сервисов XFS, так и добавлять пользовательские сервисы. Перечень запускаемых сервисов располагается в файле install.config.xml в папке FS365\XFS.

Запись о каждом сервисе – это подтег <class> в теге <configuration>.

Листинг 1. Пример записи о сервисе
 <class name="PIN">
  <helper>Класс устройств XFS.PIN</helper>
  <dllname>shqSPEPP.dll</dllname>
  <subclass name="PIN">
   <helper>PIN - модули криптования</helper>
   <model id="EPP-ZT599" psname="EPP-ZT599">
    <helper>Клавиатура ZT596(ZT599) (FW ver. D10, E10, E12, E13, F17)</helper>
    <exename>shqPS.EPP.ZT59x.exe</exename>
    <config_set>
     <param name="PORT" type="dynchoice">
      <procedure>EnumComPorts</procedure>
      <helper>Имя коммуникационного порта (COM)</helper>
      <value>COM10</value>
     </param>
     <param name="KEY_STROKE_BEEPER" type="statchoice">
      <choice>YES</choice>
      <choice>NO</choice>
      <helper>[опциональный комментарий]</helper>
      <value>NO</value>
     </param>
    </config_set>
   </model>
  </subclass>

Определение порядка запуска пользовательских сценариев

Механизм запуска пользовательских сценариев является развитием идеи механизма запуска пользовательских сервисов, однако был разработан с целью быть более удобным и гибким для конечного пользователя.

Запуск пользовательских сценариев производится посредством дополнительного, опционального файла «CustomStart.xml»

Формат файла CustomStart.xml описан и валидируется на основании содержимого файла CustomStart.xsd. Оба этих файла расположены в каталоге FS365.Starter.

В случае некорректно составленного содержимого CustomStart.xml этот файл будет проигнорирован.

В секциях actions значения атрибута «seq» указывают на очередность выполнения группы действий относительно стандартных компонентов, запускаемых FS365.Starter. Команды выполняются в порядке их указания в секциях <cmd>. Путь к исполняемым файлам, либо сценариям указывается полностью, с абсолютными путями на дисках. В противных случаях конкретная команда не будет выполнена, о чем будет произведена запись в журнале и в окне FS365.Starter. Секции <Config>, <CustomStart> и <CustomStop> являются обязательными, их порядок и количество фиксировано форматом.

Примечание

Наличие файлов CustomStart.xml и CustomStart.xsd не обязательно для функционирования FS365.Starter.
Выполнение пользовательских сценариев происходит АСИНХРОННО (FS365.Starter не дожидается завершения исполнения команды).
Доработка синхронного запуска с соответствующей опцией в секции <cmd> возможна, и будет добавлена если ее необходимость будет оправдана.

В секции <cmd> присутствует необязательный параметр «wait» с допустимыми значениями yes или no (значение по умолчанию). Параметр указывает, дожидаться стартеру завершения исполнения пользовательского сценария или нет. Необязательный параметр «params» содержит строку с параметрами запуска пользовательской команды.

Листинг 2. Пример файла CustomStart.xml
 <?xml version="1.0" encoding="utf-8"?>
 <Config>

   <CustomStart>

     <actions seq="Before_RedLabel">
       <cmd wait="yes">C:\Windows\System32\calc.exe</cmd>
       <cmd params="-djigurda">C:\Windows\System32\calc.exe</cmd>
       <cmd wait="no">C:\Windows\System32\calc.exe</cmd>
       <cmd params="-option" wait="yes">C:\Windows\System32\calc.exe</cmd>
     </actions>

   </CustomStart>

   <CustomStop>

     <actions seq="Before_RedLabel">
       <cmd>C:\Windows\System32\calc.exe</cmd>
       <cmd>C:\Windows\System32\calc.exe</cmd>
       <cmd>C:\Windows\System32\calc.exe</cmd>
     </actions>

     <actions seq="After_All">
       <cmd>C:\Windows\System32\calc.exe</cmd>
       <cmd>C:\Windows\System32\calc.exe</cmd>
       <cmd>C:\Windows\System32\calc.exe</cmd>
     </actions>

   </CustomStop>


 </Config>

Примечание

Пользовательский сценарий на любом шаге, включая «Before_All», всегда будет выполняться после выполнения стартером шага проверки целостности системы. Файл CustomStart.xml должен быть в кодировке UTF-8.

Запуск утилиты FS365.Starter

Перечень параметров командной строки:

  • START – запуск компонентов;

  • REDLABEL – опциональный запуск (только в комбинации со START) только RedLabel;

  • SUSPEND – остановка компонентов;

  • HIDDEN – запуск в скрытом режиме;

  • RUN_AS_STARTER – обеспечивает возможность запуска процесса с правами учетной записи «Starter». Может применяться в комбинации с другими параметрами командной строки.

Внимание

Если FS365.Starter в силу использования параметра командной строки RUN_AS_STARTER осуществил запуск комплекса ПО с правами учетной записи «Starter», то любые дальнейшие манипуляции над этим комплексом (завершение работы, перезагрузка, изменение состояния приложения и т.п.) должны также производиться с правами учетной записи Starter.

Команды управления питанием:

  • SHUTDOWN – выключить;

  • REBOOT – перезагрузить;

  • TURNOFF – выключить (аналог SHUTDOWN, используется исключительно для обратной совместимости, не рекомендуется к использованию).

Их (кроме TURNOFF) опциональные параметры:

  • SSD – выключающая/перезагружающая команда относится к УС;

  • NGOOS – не переходить в режим «Не обслуживает».

Перезапуск терминального ПО

При перезагрузке ПроАТИ FS365.Starter задает следующий параметр:

[HKLM\Software\XFS\PHYSICAL_SERVICES\SIU-DORS-USB]
"wdt_managed_reboot"="1"

XFS-драйвер спец. электроники DORS USB проверяет, была ли запущена перезагрузка со стороны ПроАТМ, и не отключает сторожевой таймер.

Признак режима аварийной перезагрузки – наличие флагов:

  • abnormal_termination;

  • process_name – имя процесса, в котором возникло необработанное исключение.

В данном режиме FS365.Starter выполняет особый сценарий:

  1. Трассировка входных аргументов и имени учетной записи.

  2. Захватываем глобальный мьютекс #1 с именем «FS365.STARTER.Abnormal.<process_name>.<account_name>». Если мьютекс уже занят, то прерываем работу с записью в логе. Это позволит отсечь серию однотипных развалов.

  3. Если Starter запущен под учетной записью SYSTEM, а Ogre.exe под иной, то ожидаем в течение 20 секунд возникновения исключения в другом процессе, которое приведет к вызову копии Starter’а с более предпочтительными учетными данными. Если этого не происходит, то приступаем к отработке сценария аварийной перезагрузки.

  4. Аварийная перезагрузка (по порядку):

    1. Захват мьютекса FS365.STARTER.Abnormal.DoRestart – сценарий может отрабатывать только одна копия Starter’а. Если мьютекс захвачен, то логируемся и завершаем работу процесса.

    2. Запуск AbnormalTerminationUI.exe.

    3. Перевод в OOS и штатное завершение процессов, которые не пострадали от ранее возникшего исключения.

    4. Прерывание процессов и служб, которые не удалось штатно завершить;

    5. Попытка возврата карты и наличных из Escrow – отдельный процесс IDCardAndEscrowedNotesReturn.exe.

    6. Перезагрузка: на NCR – силами UEH.exe, на остальных УС – через shutdown.exe.

Аварийный режим

Примечание

Данный функционал предназначен только для использования самой ОС.

FS365.Starter имеет специальный режим, в котором он может заменять стандартный отладчик ОС, тем самым сохраняя подробные данные о процессах, сгенерировавших необработанные исключения. Данный функционал призван упростить диагностику на удаленной УС, а также гарантировать целостность среды исполнения на УС. Последнее реализовано путем корректной перезагрузки УС в случае генерации необработанного исключения.

Настройка осуществляется установкой соответствующих значений в реестре. Настройка производится автоматически при установке ПроАТМ:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
UserDebuggerHotKey = dword:00000000
Debugger = <полный путь к утилите> -p %ld -e %ld

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
DWM.exe = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
UserDebuggerHotKey = dword:00000000
Debugger = <полный путь к утилите> -p %ld -e %ld

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
DWM.exe = dword:00000001