Calendar Server and Messaging Server now use the same stop and start mechanism. The start-cal command starts the watcher process, and then starts all other processes. The watcherprocess is aware of any dependencies the other services have, and in which sequence the services should be started.
Each registered service (process) opens a connection to the Watcher. If a process dies without properly disconnecting, the Watcher automatically restarts it. If the process dies twice in a defined interval, Watcher does not restart it. This timeout interval is configurable.
Additional Watcher information:
Automatic Restart in High Availability Deployments in Calendar Server 6.3
Starting and Stopping Calendar Server 6.3 Using Wrapper Scripts for csservice
The Watcher monitors all of the services registered with it. For Calendar Server, the registered processes are: cshttpd, csadmind , csdwpd, csnotifyd, and csstored.
The daemon csstored must be enabled. Be sure to set the configuration parameter local.store.enable to "y" . The enabling of csstored was optional in the previous version of Calendar Server, but now it is required. The csstored daemon must be successfully started before each service that accesses the store can be started. If it stops, then the dependent processes must be stopped and restarted also.
Watcher is enabled by default. To manage the Watcher process, new parameters were added to the ics.conf file:
local.watcher.enable = "y": the start program (csservice) attempts to start the Watcher before any other services. If this parameter is set to "n", then the Watcher program is disabled.
service.autorestart = "y": the Watcher automatically restarts stopped services. If set to "n", Watcher does not restart stopped services. If this parameter is set to "n" , Watcher still monitors the services and sends failure or non-response error messages to the console and the cal-svr-base/data/log file.
local.autorestart.timeout = "600": the default time within which a second server failure triggers Watcher to stop trying to do a restart.
local.watcher.port: the default port is "49994"; however, if you have Messaging Server, it will also be listening on this port and will be in conflict with Calendar Server. To avoid possible conflict, it is safer to choose a different port for Watcher to listen on.
Watcher writes to a single log, cal-svr-base/data/log/watcher.log , which contains the following information:
Failure notices and non-response error messages that were sent to the administrative console.
Records of all server stops and starts.
If a server fails twice within the timeout period, the system stops trying to restart the server. In an HA system, Calendar Server is shutdown and a failover to the other system occurs.
The public interfaces to csservice are start-cal and stop-cal. This section shows the usage for each of these wrapper scripts and contains tables with explanations of their options and a list of components to be started or stopped.
The start-cal usage is as follows:
./start-cal [options...] [components...]
The following is the list of options:
Display this help list.
Enable debugging mode.
List active services.
List enabled services.
List all services.
This following is the list of components:
watcher |
ens |
store |
notify |
admin |
http |
dwp |
If no components are listed, start-cal starts all enabled services.
The stop-cal usage is as follows:
./stop-cal [options...] [components...]
The following is the list of options:
Display this help list.
Enable debugging mode.
Force stop using SIGKILL. (This works only with UNIX® platforms.)
This following is the list of components:
watcher |
mfagent |
ens |
store |
notify |
admin |
http |
dwp |
If no components are listed, stop-cal stops all enabled services.