Startup Sequence of Sametime Services
Tags :Sametime
I was asked about this more than once this week at the seminar. Luckily Lotus had put together a technote on it but I had never ran across it I could recall. So for my records in the future and your reading, here is the technote on it.
************************************
Meeting and community servers each have their own startup mechanisms, however, both are Windows NT service-based on Win32. The following is organized by the overall startup, and then the individual startup sequences of the two components.
Sametime startup/shutdown:
The Domino server task nSTAddin is responsible for starting and stopping the Windows NT service "Sametime Server" (STLaunch.exe). This task waits until a configuration item called SametimeBootstrapInitialized equals 1 in the notes.ini file. This configuration item is set to 1 by the servlet DominoBootstrapServlet. On normal shutdown, the bootstrap servlet will reset the value to 0. On forced shutdown, the next startup will probably already have the value 1 and the nSTAddin task will not wait. This is not catastrophic as long as you have not made custom port modifications to the EventServerPort, which is typically 9092.
STLaunch will start the Windows service Sametime Meeting Server (stmsservice.exe). Upon launching, this will wait for two minutes. The assumption being that the CPU and disk will be taxed while starting up the subtasks, so it waits a bit before proceeding.
STLaunch will next start the service ST Community Launch (STCommLaunch.exe). STLaunch does not monitor the stmsservice or STCommLaunch.
After Sametime has started, the nSTAddin task reports "Sametime Running" even if the services are shut down manually or abnormally (this is a known issue). The command "tell staddin quit" will cause the STLaunch service to shutdown. STLaunch will tell the Windows service for meeting and community to shutdown.
Meeting server startup/shutdown:
The service stmsservice.exe spawns the process nSTMeetingServer.exe. This is a Domino server task, and at some point could be started and stopped using the Domino console commands. However, it is not recommended to do so in a production environment.
nSTMeetingServer launches the IBM JRE Java VM with arguments that will start the event server process.
Once the event server has started, it is connected and then the rest of the services are started.
Meeting server services are found in the registry and will be started in order, based on the following StartOrderDependencies value:
HKLM\Software\Lotus\Sametime\MeetingServer\Services
This is where the services are configured.
Service startup and shutdown are controlled. Events on the event system are used to signal success/failure.
The StartWaitTime and StopWaitTime values determine the amount of time to wait for a success. Because startup is controlled, failure to receive a startup event will result in shutdown of the started services.
There are four main service types:
0: Standard process
Process is launched and a service start event should be received by the launcher indicating success.
1: Java service requiring new JVM - several services are implemented in Java.
Where possible (and appropriate), Java services may be started and stopped within a single JVM. This service type is for those services which require a new JVM. There is a service called the Java Service Manager which is of this type, but is built to handle running all of the other Java services within its VM.
2: Java service - any service that may be run within the single Java Service Manager JVM.
The Java Service Manager will use the startup arguments to dynamically load the Java class, which must implement the com.lotus.sametime.stjavaservices.STService interface.
3: Event Server - this is the special event server service.
It is a Java service that is started within its own VM (like service type 1), but it is special in that there can be only one event server. The launcher has special startup control mechanisms when it is started.
When the stmsservice is told to stop, it signals the nSTMeetingServer process to stop all of the meeting server services. The meeting server service shutdown is controlled in the same order as startup. Meeting server services are not restarted in the event that something fails during runtime.
Community server startup/shutdown:
The service STCommLaunch.exe starts each of the community Windows services. It reads the file STCommLaunch.dep for a list of service names and starts the Windows services in that order.
STCommLaunch.dep
# This is a dependency file for VpLaunch.exe
SERVERAPP ST Community
SERVERAPP ST Configuration,ST Community,SOFT
SERVERAPP ST Logger,ST Community,SOFT
SERVERAPP ST Places,ST Community,SOFT
SERVERAPP ST Users,ST Community,SOFT
SERVERAPP ST OnlineDir,ST Community,SOFT
SERVERAPP ST BuddyList,ST Community,SOFT
SERVERAPP ST Conference,ST Community,SOFT
SERVERAPP ST Directory,ST Community,SOFT
SERVERAPP ST Chat Logging,ST Community,SOFT
SERVERAPP ST Polling,ST Community,SOFT
SERVERAPP ST Links,ST Community,SOFT
SERVERAPP ST Resolve,ST Community,SOFT
SERVERAPP ST User Storage,ST Community,SOFT
SERVERAPP ST Privacy,ST Community,SOFT
SERVERAPP ST Mux,ST Community,SOFT
SERVERAPP ST Admin Service,ST Community,SOFT
SERVERAPP ST SIP Gateway,ST Community,SOFT
If a process fails, the STCommLaunch will attempt to restart it a few minutes later.
On shutdown, STCommLaunch will stop each of the community services.
Special notes:
Two of the meeting server services use community functionality (GWController and ActivityProvider). Both of these services have re-try connection logic that will cause them to re-connect to community if it is not yet running or if it has been shutdown/restarted. On normal startup, you will see that the meeting server will start before the community server, so there will be a few minutes where the community connection logic will fail to connect. Eventually, the connection will be made.
The STLogger.exe community service may experience problems starting and stopping if the meeting server ConfigurationBridge and/or ConfigurationServlet are not running. It is for this reason that the startup order changed from 2.5 to 3.0 (Community started first in Sametime 2.5). If the configuration services are not available, then by default Notes logging will be performed (not file logging if you've configured that).
To determine if a community service is being restarted due to an abnormal/recurring shutdown, take a look at sametime.log. You will see normal shutdowns indicated by the Terminated message. You will see startups indicated by the Initialized message. If you see Initialized all by itself (and not following a Terminated), it typically means that the process has gone away and has been restarted. This may result in instability and should be corrected.
To determine if a meeting service has shutdown abnormally, you can look at the admin status page for a list of all running processes (and what's not running). Meeting services will not restart automatically, so you should be able to identify errant processes fairly quickly. These should be corrected.
blog comments powered by Disqus
On Friday, October 27th, 2006 by Chris Miller
