Доброе время суток!

Возникла такая проблема: есть сервис, который выполняет достаточно важную работу постоянно (не по запросу), т.е. в сервисе запущен поток по команде запуска сервиса; необходимо поймать его зависание и сообщить специалисту (сервис — на серваке, специалист — в локалке).
Собственно проблема в том, как определить "заклинивание" потока (там есть обращения к FTP, SQL, что-то может сломаться там; может сглючить сам процесс — работать должно в идеале годами) и что-то сделать.
В настройках сервиса есть понятие "сбой службы", при котором будет сделан перезапуск. Но как этот сбой определяется? Я пробовал в потоке /0 — без реакции вообще В описании сервисов ничего не нашёл, только про ошибки пуска/останова.

Может, кто-нибудь уже решал такое?

Здравствуйте, port443, Вы писали:

P>Доброе время суток!

P>Собственно проблема в том, как определить "заклинивание" потока (там есть обращения к FTP, SQL, что-то может сломаться там; может сглючить сам процесс — работать должно в идеале годами) и что-то сделать.

А можно четко сформулировать, что в данном случае означает "зависание" потока?
С точки зрения сервиса, т.е. для серсива повисший поток — это что?

Здравствуйте, rus blood, Вы писали:

RB>Здравствуйте, port443, Вы писали:

P>>Собственно проблема в том, как определить "заклинивание" потока (там есть обращения к FTP, SQL, что-то может сломаться там; может сглючить сам процесс — работать должно в идеале годами) и что-то сделать.

RB>А можно четко сформулировать, что в данном случае означает "зависание" потока?
RB>С точки зрения сервиса, т.е. для серсива повисший поток — это что?

Вот в том-то и непонятки:
— для SCM любые проблемы потока не видны: он его не замечает, т.к. сам за ним не следит;
— как я понимаю (правильно ли? поправьте), SCM не проверяет состояние сервиса вообще, кроме как в случаях, когда этого хочет приложение (QueryServiceStatus) (или тоже не проверяет, а берёт то, что сервис сказал при старте?).
В связи с этим вопрос: кто-нибудь знает, что означает "первый сбой", ... в настройках сервиса? Как его SCM определяет?

Была даже идея запускать ещё один поток, который следит за первым по более-менее регулярно поднимаемому Event и сообщает... но как перезапустить-то его? SCM-у не сообщить, такой функции нету; можно-ли из потока перезапустить весь сервис?

Кое-что найдено: был глюк то-ли в ДНК, то-ли в VC... после очередной пересборки деление на ноль наконец стало вызывать тот самый "сбой"
Теперь идея с автоперезапуском будет проверена... о результатах напишу.

В общем резюме пока такое:
1. Глюк с /0 был в оптимизации компилятором кода: так как результат деления я не использовал, то и код деления не компилировался
2. При делении на 0 сервис падает, SCM его действительно ловит и перезапускает, НО: выдается диалог типа "приложение выполнило...", и пока его не закроешь — ни рестарта сервиса, ни сообщения в лог, ни запуска приложения... в общем пока админ не придёт и не увидит всё лично — тишина.
На сейчас идея такая: основной поток при работе "пульсирует" Event-ом, параллельный поток следит за пульсом, и, в случае его пропадания должен ронять сервис... Пока не понятно, как быть с п.2

Привет!

port443 wrote:
> 2. При делении на 0 сервис падает, SCM его действительно ловит и перезапускает, НО: выдается диалог типа "приложение выполнило...", и пока его не закроешь — ни рестарта сервиса, ни сообщения в лог, ни запуска приложения... в общем пока админ не придёт и не увидит всё лично — тишина.

SetUnhandledExceptionFilter

--
With best regards,
Pavel Dvorkin

>> 2. При делении на 0 сервис падает, SCM его действительно ловит и перезапускает, НО: выдается диалог типа "приложение выполнило...", и пока его не закроешь — ни рестарта сервиса, ни сообщения в лог, ни запуска приложения... в общем пока админ не придёт и не увидит всё лично — тишина.

PD>SetUnhandledExceptionFilter

Не получается
А что фильтр должен возвращать? EXCEPTION_EXECUTE_HANDLER?
Не помогло даже в комплекте с SetErrorMode( SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX );

Hello, port443!
You wrote on Tue, 24 Aug 2004 09:41:35 GMT:

p> В общем резюме пока такое:
p> 1. Глюк с /0 был в оптимизации компилятором кода: так как результат
p> деления я не использовал, то и код деления не компилировался 2. При
p> делении на 0 сервис падает, SCM его действительно ловит и перезапускает,
p> НО: выдается диалог типа "приложение выполнило...", и пока его не
p> закроешь — ни рестарта сервиса, ни сообщения в лог, ни запуска
p> приложения... в общем пока админ не придёт и не увидит всё лично -
p> тишина. На сейчас идея такая: основной поток при работе "пульсирует"
p> Event-ом, параллельный поток следит за пульсом, и, в случае его
p> пропадания должен ронять сервис... Пока не понятно, как быть с п.2

SetErrorMode(SEM_NOGPFAULTERRORBOX) попробуй

With best regards, Sergey.

Привет!

port443 wrote:
>
> >> 2. При делении на 0 сервис падает, SCM его действительно ловит и перезапускает, НО: выдается диалог типа "приложение выполнило...", и пока его не закроешь — ни рестарта сервиса, ни сообщения в лог, ни запуска приложения... в общем пока админ не придёт и не увидит всё лично — тишина.
>
> PD>SetUnhandledExceptionFilter
>
> Не получается
> А что фильтр должен возвращать? EXCEPTION_EXECUTE_HANDLER?
> Не помогло даже в комплекте с SetErrorMode( SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX );

Я сейчас попробовал

#include "stdafx.h"
#include "windows.h"

LONG WINAPI MyUnhandledExceptionFilter(
_EXCEPTION_POINTERS* ExceptionInfo)
{
printf("we are here\n");
return EXCEPTION_EXECUTE_HANDLER;
}

int main(int argc, char* argv[])
{
SetUnhandledExceptionFilter(MyUnhandledExceptionFilter);

int f=0;
int y= 1/f;
return 0;
}

благополучно заканчивается без окна (не под отладчиком, конечно)

--
With best regards,
Pavel Dvorkin

СПАСИБО!

Всё заработало как надо
Не в том месте поставил SetErrorMode/SetUnhandledExceptionFilter: поставил сразу за StartServiceCtrlDispatcher()

В документации же написано:
If StartServiceCtrlDispatcher succeeds, it connects the calling thread to the service control manager and does not return until all running services in the process have terminated.
\