"TonyG" <TonyG@junk.com> wrote in message
news:uDQsj.1632$fX7.704@nlpi061.nbdc.sbc.com...
I have written a service that is scheduled to start automatically. On
startup, if my service encounters a severe problem that prevents
proper operation, how should the service handle this situation?
Currently my service does the following:
1) Post descriptive text in the program's log.
2) Post descriptive text in the operating system's event viewer log.
3) Wait 60 seconds and then terminate.
I prefer to be much less rude to the rest of the system. Filling the
system log and/or a service waiting 60 seconds before failure
termination during startup are rude IMO :)
For the system log I personally use up to maybe 4 entries: one that
says my service is starting, one that says it's successfully
running/connected/whatever applies, one for failure (with some error
info if possible), and one for shutdown. Of course, if you need an
entry for every attempt, then there's not much choice. If I only see
the "starting" entry then I know it hasn't successfully started yet -
a good time to attach a debugger if necessary.
As far as the 60 second wait goes, if the potential startup problem is
generally corrected with time, then the service startup code should
spawn another thread that handles startup and return control to the
SCM ASAP. Then that spawned thread can take as long as it needs to
establish a good running state, without slowing down the entire system
startup.
Just my 2 cents,
Mark