Форум Академгородка, Новосибирск > XP: удалённо перезапустить сервис
Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: XP: удалённо перезапустить сервис
Форум Академгородка, Новосибирск > Компьютеры и сети > Операционные системы > Windows
lost_shadow
Есть один сетевой сервис под windows. Иногда он перестаёт обслуживать своих клиентов и его нужно перезапустить. Проблема в том, что зависать последнее время он стал несколько раз за день, а во время простоя останавливается работа нескольких десятков человек, прекращается обслуживание читателей библиотеки. Обучить персонал перезапускать сервис удалённо возможности нет, присутствовать всё рабочее время недалеко от компьютера и отвечать на звонки, прерывая сон каждые 3 часа нет желания. Выход - система мониторинга и перезапуск сервиса в случае проблем.

Когда монитор обнаруживает, что сервер ведёт себя не должным образом, нужно попробовать перезапустить сначала сервис, затем, если не помогло, "мягко" выключить и включить виртуальную машину с ним, после пробовать перезапускать остальные глючные компоненты системы. Причём сделать всё это нужно удалённо, с другой машины. И у меня проблемы с перезапуском сервиса на windows и корректным выключением windows-машины.

Попытки решить одну частную задачу - перезапустить сервис через
Код
wmic -U USERNAME%PASSWORD //ADDRESS 'service where caption="SVCNAME" call startservice'
или
Код
net rpc -I ADDRESS -U USERNAME%PASSWORD service {stop|start} SVCNAME
не привели к успеху, гугление и копание никакого эффекта не дало. Хочется, чтобы подобных проблем не возникло и в дальнейшем - решение по возможности должно основываться на открытом и стандартном протоколе, должно позволять запускать на удалённом windows любой понравившийся код.

Мне видятся следующие варианты решений:
  1. Поискать существующие решения - поставить SSH-сервер, настроить авторизацию по ключу и запускать с сервера монитора что-то вроде
    Код
    ssh ADDRESS 'net stop SVCNAME; net start SVCNAME'
    Минус решения - openssh под windows не обновлялся с 2004 года, в сети описаны проблемы при поднятии сервера и авторизации по ключу. Прочие SSH-сервера либо хотят денег, либо в таком же, плачевном состоянии.
    Cygwin мне так же отсоветовали из-за его кривоухости.
  2. Использовать вместо ssh существующий telnet service. Не подошло, так как после открытия, закрытия подключения и открытия нового windows сделал вид, что лимит подключений исчерпан и отказался обслуживать телнет-клиента. Такие баги в этой задаче недопустимы.
  3. Собственноручно написанный сервис. Мне влом осваивать сервисописание под windows. Если есть какая-то программа вроде линуксового daemon, делающая демон из любого понравившегося скрипта, это было бы очень кстати. В сети есть упоминание некоего srvany, но, как я понимаю, она работает только с exe-шниками и непонятно, где её можно, такую хорошую, скачать.
  4. Ежеминутно запускаемый из планировщика скрипт, проверяющий наличие определённого файла в определённом месте на определённом самба-сервере. И таким вот макаром реализовать обмен данными между серверами. Кривое решение само по себе.
  5. Поднять веб-сервер, CGI-скрипт. Ну или не CGI - apache+mod_python тоже подойдут. Решение возможно, но тяжеловато.

Идеальным было бы, конечно, первое решение, как наиболее стандартная и знакомая схема выполнения программы на удалённой машине.
Все эти вопросы я рассмотрел поверхностно. Вполне вероятно, я что-то упустил и решение лежит на поверхности, ведь не может такая элементарная задача решаться таким сложным образом.
Идеи, соображения, мысли?
:::
Непонятно, каким образом определять, что сервис перестаёт обслуживать клиентов? как я понял, он ведь не вылетает, ведь тогда просто стандартная мера - перезапуск в случае сбоя (свойства сервиса, восстановление). Для удалённого администрирования удобна Dameware NT Utility.
lost_shadow
Да, он ещё и вылетает - это я решил именно таким способом. Но тут всё сложнее - иногда он не вылетает, но закрывает TCP-порт. А иногда не вылетает, не закрывает TCP-порт, но и не отслыает ответы на запросы клиентов.

Понять, что сервис всё ещё работоспособен, можно. По крайней мере, он работает по бинарному, кривому и древнему, но стандартному протоколу z39.50. Можно подключиться к серверу и раз в некоторое время выполнять несложный тестовый запрос. С реализациями этого протокола тоже большие проблемы, но можно, по крайней мере, использовать для коммуникации с сервером готовую программу yaz-client.
skif
Самое простое решение, приходящее на ум - запускать сервис как службу, и поставить в настройках перезапуск при сбое.
Ну и самое правильное - разобраться, почему сервис падает :-)
:::
Цитата(skif @ 02.01.2011, 23:10) *
Самое простое решение, приходящее на ум - запускать сервис как службу, и поставить в настройках перезапуск при сбое.
Ну и самое правильное - разобраться, почему сервис падает :-)

Об этом уже написано. А самое правильное не всегда самое эффективное.
lost_shadow
Цитата(skif @ 02.01.2011, 23:10) *
поставить в настройках перезапуск при сбое.
Про это я уже писал.

Цитата(skif @ 02.01.2011, 23:10) *
Ну и самое правильное - разобраться, почему сервис падает :-)
Техподдержка в курсе уже как 3-4 месяца, всевозможные логи постоянно отсылаются, деньги техподдержке отправляются, но результатов нет.
academw
перезапускать по расписанию каждые 2 часа
:::
Цитата(academw @ 03.01.2011, 21:38) *
перезапускать по расписанию каждые 2 часа

Очень умно, представляете негодование пользователей? особенно когда выяснится, что это преднамеренная акция...
havoc
Цитата(::: @ 03.01.2011, 21:46) *
Цитата(academw @ 03.01.2011, 21:38) *
перезапускать по расписанию каждые 2 часа

Очень умно, представляете негодование пользователей? особенно когда выяснится, что это преднамеренная акция...

так если тс пишет что сервис несколько раз в день падает, юзерам уже привычно.
при любом подходе, сбоев неизбежать, так пусть уж лучше они будут плановые. если, конечно, сервис 100% не упадет в промежутки между перезапусками
lost_shadow
Тут всё сложнее - сессия пользователя начинается с момента подключения к серверу и заканчивается моментом отсоединения. Во время сессии пользователь создаёт или редактирует записи. У клиентского ПО есть две нехороших особенности:
  1. После обрыва соединения несохранённые данные теряюся.
  2. Сохранить запись можно только закрыв её представление, которое открывать довольно долго - иными словами, жать "save" раз в 5 минут не получится.
Редактирование одной записи занимает от нескольких минут до нескольких часов. Соответственно, при рестарте сервера каждые 2 часа мы как теряем львиную долю работы, так и всё равно имеем в среднем час простоя после падения сервера.

:::
Вобщем, надо доводить сервис до ума, иначе можно долго упражняться.
lost_shadow
Исходный код нам не дают, так что это не в наших силах.
:::
Главная проблема - потеря клиентских данных при падении сервера, перезапуск ничего не поправит.
lost_shadow
Перезапуск уменьшит время простоя, это тоже крайне важно. Отделам, у которых операции очень маленькие по времени (выдача/приём литературы, изменение сведений о читателе) нужно достичь именно минимального времени простоя. Перезапуск сервиса в момент отказа - лучшее, что мы можем позволить себе позволить, хотя надежды на исправление ошибки разработчиками мы всё ещё не теряем.
Из фильма
Я, может быть, не внимательно прочитал все, но что мешает использовать RDP соединение с сервером, как некий аналог SSH?
lost_shadow
То, что этот процесс должен быть автоматическим - запускаться из sh-скрипта на другой машине, например.
Gort
я бы hudson использовал
lost_shadow
Up. Проблема всё ещё актуальна.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Русская версия IP.Board © 2001-2024 IPS, Inc.