[Date Prev][Date Next]
RE: new code for slapd as NT service
At 09:27 AM 6/18/99 +0200, Paul Higgs (EBC) wrote:
>One area of immediate concern is the correct interaction with the Windows NT
>Service Control Manager (SCM), especially during startup and shutdown
I am just a little concern that some folks might assume that the port is
stable enough to be ran as a service just be service manager support is
>The SCM expects to receive SERVICE_START_PENDING message at some
>pre-described intervals until startup processing is complete, at which case
>a SERVICE_RUNNING message should be sent.
>If the SCM does not receive either of these messages before the prevoius
>WaitHint lapses, it issues an assassin to kill the process and reports the
>error "The service failed to respond" (or something like that)
I think we should, at least for now, just increase the wait hint
to some appropriately large value (like MAXINT).
>I found that after buildig the latest source, that I was getting this error,
>and tacked it down to an exit(1); call in attr_syntax_config. This was
>because my XXX.at.conf files defined an attribute twice and was easy enought
>to fix, but it highlights the problem of having several exit points in the
>Because of the exit() call, I am unsure if all opened resources were closed
Fault handling is a major TODO items... we are working on bubbling
up faults, but it going to be a long while before all the exit() calls
>Somehow we need to find a way to clean up the termination processing.
I think we already have a way that will work once we take care of fault
>Also to note is the use of exit() after a SERVICE_RUNNING message is sent to
>the SCM. In this case, no trace of the process will exist in the system
>memory, but the SCM database will still show the service as running.
>Attempting to stop the service from the SCM Control Panel applet will
>eventually result in the message "The service failed to respond to the
>The the service had sent a SERVICE_STOPPED message to the SCM before calling
>exit() then the SCM database would reflect the correct operational state.
There should be no exit() calls and eventually there will be none.
All detected faults will be bubbled up and dealt with appropriately.
There should only be one entry and one exit point.
Placing additional side effects upon each exit() call would be unwise
as it would make removal of the exit() calls harder.
For now, I am content with considering exit() calls as crashes.
On crash, I'd expect "The service failed to respond to the control function."