Взаимодействие с процессом Services.exe

← →
Digitman (2002-12-25 13:52) [0]

1. Стартовано приложение Services.exe

2. Некий мой сервис, имея статус "Started", нормально отображается в списке сервисов (визуализируемом приложением Services.exe)

3. В некий момент времени мой сервис переходит в состояние Stopped

4. Приложение Services.exe продолжает отображать статус моего сервиса как Started до момента, пока я вручную не обновлю статус вызовом Refresh-меню. Это вполне естетсвенно, поскольку стоп сервиса инициирован не средствами Services.exe.

Господа, какие будут идеи по поводу того, как мне программно (из кода самого моего сервиса после перевода его в Stopped-состояние) известить процесс Service.exe о необходимости выполнить Refresh (если не соответствующего элемента списка, то хотя бы - всего списка сервисов) ?

Вероятно, у Service.exe и/или его гл.окна есть какие-то "зацепки" (фикс. оконные сообщения либо недокум. интерфейсные входы), дабы иметь возможность осуществить сабж

Заранее благодарен за небредовые идеи)

← →
Набережных С. (2002-12-25 15:53) [1]

А вариант, когда сервис сам извещает об изменении своего статуса, не подходит?

← →
Digitman (2002-12-25 16:13) [2]

>Набережных С

Нет, не подходит. Ибо Services.exe совершенно независимо (только в момент нач.инициализации и в момент Refresh) вызывает QueryServiceStatus() и в результате получает актуальный статус сервиса.

← →
Набережных С. (2002-12-25 16:14) [3]

>как мне программно (из кода самого моего сервиса после перевода его в Stopped-состояние) известить процесс Service.exe о необходимости выполнить Refresh (если не соответствующего элемента списка, то хотя бы - всего списка сервисов) ?

Невнимательно прочитал первый раз. Например, по именованному каналу непосредственно перед изменением статуса callback-функции.

← →
Набережных С. (2002-12-25 16:16) [4]

Как я понял, это твой сервис? Или нет? Если твой, то почему не использовать канал?

← →
Набережных С. (2002-12-25 16:18) [5]

"статуса callback-функции" читать как "статуса в callback-функции" :)

← →
Digitman (2002-12-25 16:24) [6]

Да, мой процесс моего сервиса. Т.е. подконтролен мне от и до.

И как ты себе это видишь - использование канала ? В общих чертах, пожалуйста. Я, к примеру, не в курсе, что процесс Service.exe создает какой-то именованный прогр.канал, к которому я мог бы обратиться из кода своего сервиса. Да и каково имя канала, каков протокол инф.обмена, если канал таки создается процессом Service.exe ? Тоже не в курсе как бы ...

← →
Набережных С. (2002-12-25 16:56) [7]

Схема может быть примерно такой.
Service.exe на старте создает именованный канал с известным сервисам именем и извещает об этом факте сервисы через SCM. В сервисе в теле callback-функции(ну той, которую регистрируют через RegisterServiceCtrlHandler на старте потока сервиса) либо в теле самого сервиса при получении требования об изменении статуса открываем этот канал (CreateFile) и отправляем по нему соответствующее уведомление, а уже потом изменяем состояние сервиса. А в Service.exe следить за каналом можно асинхронно или в доп. потоке. Единственно, нужно будет права доступа к каналу разрулить, но это не сложно.
Либо без извещений, сервис перед изменением статуса пытается открыть канал, если получилось - извещает, нет - Service.exe не запущена.
А протокол - свой, как и с сокетами. Да и вместо именованного канала, вероятно, можно использовать непосредственно сокеты, попробуй.

← →
Набережных С. (2002-12-25 17:19) [8]

Да, именованный канал - CreateNamedPipe :)

← →
Digitman (2002-12-25 17:21) [9]

и что мне это даст ? imho, ничего

← →
Набережных С. (2002-12-25 17:52) [10]

>и что мне это даст ? imho, ничего

То есть? Возможно, я не понимаю сути проблемы?

← →
Набережных С. (2002-12-25 18:04) [11]

Еще раз тебя процитирую:
"как мне программно (из кода самого моего сервиса после перевода его в Stopped-состояние) известить процесс Service.exe о необходимости выполнить Refresh"
По-моему именно это и получится... Только извещать нужно перед самым переводом в Stopped, потому как Stopped означает Остановить все потоки данного сервиса. Нет, решительно не вижу, чем не устраивает. Единственно, что добавить: callback вызывается в контексте главного процесса приложения, следовательно, в ней можно дождаться фактической остановки сервиса и уже тогда отправлять извещения об остановки.
Все-таки изложи подробнее, что именно не нравится.
И, кстати, сервис - дельфийский или на АПИ?

← →
Внук (2002-12-25 18:30) [12]

>>Набережных С.
Imho, Вы не так поняли вопрос. Тот самый Services.exe, который упомянут в первом посте Digitman, это не некий абстрактный сервис, а тот самый SCM и есть. :)) И заставить его создать именованнный канал не представляется возможным. В другом направлении надо передавать - не от SCM к сервису, а от сервиса к SCM...
>>Digitman ©
Подозреваю, что ответ есть у Рихтера и Кларка. Дома постараюсь посмотреть...

← →
Набережных С. (2002-12-25 18:49) [13]

Кажется, понял.
>визуализируемом приложением Services.exe

Вот что меня сбило.
Services.exe - это приложение, содержащее SCM и некоторые сервисы. В W2k "визуализацией" занимается MMC.exe плюс плагины в виде ActiveX DLL. Нужно найти соответствующий плагин и "пощупать" его интерфейсы.

← →
vuk (2002-12-25 18:54) [14]

Вот как раз у Рихтера с Кларком ничего подобного и нет...
На мой взгляд, если уж приложение, управляющее сервисами не может отслеживать их состояние, то это проблема управляющего приложения, а не сервисов. Универсального способа все равно не найти, потому как программы управления сервисами могут быть самые разные.

Вообще говоря, в данном случае ничего не приходит в голову кроме банального поиска окна и нажатия кнопки.

← →
Набережных С. (2002-12-25 20:06) [15]

>Digitman ©

Поройся в MSDN в разделе Management Services. У ММС есть несолько интерфейсов, может чего найдешь.
А обсудить саму задачу нет желания?

← →
Digitman (2002-12-26 09:01) [16]

Ну, положим, services.exe не содержит собственно ядро SCM. Это всего лишь утилита-оболочка, штатно поставляемая с ОС. С таким же успехом любой неленивый и сам бы эту утилиту "нарисовал")

> обсудить саму задачу нет желания?

Да есть, конечно. Проблема-то пока не разрешена)
Еще раз уточню - я ищу путь заставить "чужой" процесс Services.exe отражать изменения статуса моего сервиса (взаимодействующего с SCM как положено - через его "родные" ф-ции, начиная с OpenSCManager() и т.д. и т.п.), в случае, если изменения статуса производит сам мой сервис (а не приложение services.exe)

← →
Digitman (2002-12-26 12:45) [17]

Прошу прощения. Наврал ведь с три короба я !)

Конечно же консоль, занимающаяся мэнеджментом сервисов, это - не services.exe

Это - services.msc (services console), в контексте исполнения которой стартует mmc.exe, собссно и являющийся универс.оболочкой

Так что - спасибо <Набережных С.> за направление поиска.

Но проблема пока - все та же, только акцент поиска переместился на ActiveX-плагин соответствующий

Я так понимаю, что ком.строка "serviсes.msc /s" стартует mmc-процесс с указанием ему необходимоти загрузки и инициализации плагина для менеджмента объектов-сервисов

← →
Набережных С. (2002-12-26 15:37) [18]

Должен предупредить, что мое знакомство со всем этим довольно поверхностное. Просто ознакомился в общих чертах, притом довольно давно, так что запросто могу чего-нибудь соврать:)

Файлы с расширением .msc - конфигурационные специального формата. Это расширение ассоциировано с приложением MMC.exe. Вероятно, содержат списки плагинов и настройки.

Что касается плагинов. Список всех плагинов находится в подразделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns. Посмотрел, похоже, с сервисами работает объект SvcVwrObject из файла WINNT\System32\filemgmt.dll. Вот только толку с этого немного. Библиотека типов в нем есть, но в ней только список классов и интерфейсов - без методов :( Похоже, это направление - тупиковое. Надо попробовать добраться через интерфейсы MMC.

← →
Digitman (2002-12-26 16:34) [19]

Спасибо за идею.
Плагины посмотрел под лупой, тоже ничего полезного не обнаружил. Зацепиться там вроде бы не за что.

На сей момент я тоже склоняюсь к детальному исследованию именно MMC.

← →
Внук (2002-12-26 17:25) [20]

А все-таки именно в упомянутой мной книге совершенно четко говориться, что не существует способа, которым сервис может уведомить об изменении своего статуса. Единственный и некрасивый способ - это когда SCP (не SCM) периодически сама опрашивает сервис, например, по таймеру. Буду рад, если ошибаюсь...

← →
Набережных С. (2002-12-26 18:13) [21]

>Внук © (26.12.02 17:25)

Да уведомить-то не проблема, если SCP(или какой-нибудь виевер) и сервис сам писал(см. >Набережных С. (25.12.02 16:56)). А здесь нужно заставить плагин в MMC обновить инфу. Подождем, что найдет Digitman :)

Взаимодействие с процессом Services.exe Найти похожие ветки