В основном мы работаем с Linux, но у нас есть принт-сервер под управлением Windows Server 2008, и мы используем приложение Print Helper для печати счетов. Мне нужно найти способ проверить, запущено ли это приложение, и автоматически перезапустить его, если это не так.
В Linux я бы, вероятно, сделал это с помощью небольшого сценария оболочки и задания cron, но я не уверен, как это сделать на Windows Server. Я вполне уверен, что смогу сделать это в Perl, используя Proc :: Background, но я не хочу устанавливать Perl только для одного скрипта, и хотя я уверен, что это можно сделать с помощью чего-то вроде PowerShell, на самом деле это не стоит потратить свое время на изучение PowerShell для одной небольшой задачи. Tasklist, кажется, делает кое-что из того, что я хочу, так как он может сообщить вам, запущен ли конкретный процесс или нет, но я не уверен, как я могу перейти оттуда к автоматическому перезапуску приложения в случае его сбоя.
Любая помощь с благодарностью получена!
Вот это да. Я просто ответил на другой вопрос.
Что вам следует сделать, так это «демонизировать» процесс Помощника печати с помощью sc.exe или srvany.exe (который, я считаю, обесценивается). Затем вы можете использовать параметры встроенной службы «Восстановление» для обработки событий сбоя (включая, как мне кажется, выполнение сценария, отправку ловушки snmp, отправку электронной почты и, конечно же, перезапуск службы).
Как указано:
sc create printhelper binpath= "c:\program files\Print Helper\phelper.exe" start= auto depend= Spooler/lanmanserver DisplayName= "Print Helper"
Это создаст службу с именем printerhelper
, с отображаемым именем Print Helper
, выполняя "c:\program files\Print Helper\phelper.exe"
автоматически, с зависимостями службы диспетчера очереди печати и сервера SMB / CIFS, работающей как NT AUTHORITY\SYSTEM
встроенный пользователь.
Если вы используете Nagios, вы можете сделать это с помощью надстройки NSClient ++.
На сервере мониторинга определите службу:
define service{
use generic-printer
host_name hostname
service_description appname
check_command check_nt!PROCSTATE!-d SHOWALL -l appname.exe
contact_groups admin-sms
event_handler autostart_appname!hostname
}
В autostart_appname
определяется в commands.cfg
:
define command {
command_name autostart_appname
command_line $USER1$/eventhandlers/autostart_appname.sh $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ $HOSTADDRESS$
}
Скрипт обработчика событий autostart_appname.sh
:
#!/bin/sh
HOSTADDRESS=$4
case "$1" in
OK)
;;
WARNING)
;;
UNKNOWN)
;;
CRITICAL)
case "$2" in
SOFT)
;;
HARD)
/usr/local/nagios/libexec/check_nrpe -H $HOSTADDRESS -c autostart_appname
;;
esac
;;
esac
exit 0
На сервере Windows определите команду в NSC.ini
:
[NRPE Handlers]
autostart_appname=C:\Program Files\NSClient++\scripts\autostart_appname.cmd
а пакетный скрипт очень прост:
net start "Application Name"
Похоже, вы хотите уделять этой задаче как можно меньше времени. Мы все одинаково ненавидим серверы печати. Используя только настройки, встроенные в Windows, вы можете создать службу, автоматически восстановить службу и реализовать элементарный мониторинг службы.
Шаг 1 Создайте услугу
(Вы можете пропустить этот шаг, если в панели управления службами уже есть запись о службе)
Используйте sc.exe для создания новой службы.
sc.exe create PrintHelper start=auto binPath="C:\<Print Helper Path and Flags>" DisplayName="Print Helper"
Шаг 2 Настройте свой сервис
В панели управления службами щелкните правой кнопкой мыши новую службу, выберите свойства и выберите вкладку «Восстановление». Настройте по мере необходимости.
Здесь есть много вариантов, что делать при первом сбое, при втором сбое, вы даже можете запустить другое приложение при сбое.
Шаг 3 Контролируйте свою службу
Либо настройте средство просмотра событий для отправки электронного письма о сбоях определенного события для помощника по печати (найдите событие, щелкните его правой кнопкой мыши, выберите «Присоединить задачу» для этого события).
Или настройте Службу для отправки электронного письма в случае сбоя, используя внешнюю программу в качестве механизма восстановления.
Отказ от ответственности
Конечно, я бы порекомендовал использовать что-то вроде nagios или SCOM для реального решения для мониторинга. Но это совершенно новая проблема сама по себе.