Chapter 10 Administering Calendar Server

This chapter describes how to administer Calendar Server, and contains the following sections:

You manage Calendar Server by running command-line utilities and by editing the ics.conf configuration file.

To run the command-line utilities, you must log in as a user who has administrative rights to the system where Calendar Server is running.

Starting and Stopping Calendar Server



Note	Calendar Server provides the csstart and csstop utilities only for compatibility with earlier releases. If possible, use the start-cal and stop-cal utilities to start and stop Calendar Server.

Using the start-cal and stop-cal Utilities

The start-cal and stop-cal utilities are located in the cal_svr_base/opt/SUNWics5/cal/sbin directory. You must run these utilities on the local machine where Calendar Server is installed. For problems that might occur, see Troubleshooting the start-cal and stop-cal Utilities.

The start-cal utility starts Calendar Server services in the following order:

enpd — Event Notification Service (ENS)

csnotifyd — Notification Service

csadmind — Administration Service

csdwpd — Database Wire Protocol (DWP) service, the distributed database service that is started only with a remote Calendar Server database configuration

cshttpd — HTTP Service

To start Calendar Server using the start-cal command:

To stop Calendar Server using the stop-cal command:

Change to the cal_svr_base/opt/SUNWics5/cal/sbin directory.

Stop Calendar Server:

./stop-cal

Troubleshooting the start-cal and stop-cal Utilities

When you are starting and stopping Calendar Server, the following problems might occur:

The start-cal utility does not start all Calendar Server processes. For example, start-cal might start the enpd, csnotifyd, and csadmind processes but not cshttpd. In this situation, you must stop all Calendar Server processes before you try to restart Calendar Server.

The stop-cal utility does not stop all Calendar Server processes. For example, stop-cal might stop the cshttpd parent process but not any cshttpd child processes. In this situation, you must stop the remaining Calendar Server processes.

On Linux systems with Calendar Server running, if you search for calendar processes using the ps command, the results might appear confusing. In Linux, the ps command returns the list of threads running rather than the list of processes.There is no known workaround to display only the processes.

To stop Calendar Server processes on Solaris Operating Systems:

Determine the process ID (PID) of the remaining Calendar Server processes by entering a ps command for each service:

ps -elf | grep cs-process

where cs-process is enpd, csnotifyd, csdwpd, csadmind, or cshttpd. For example:

ps -elf | grep cshttpd

Using the PID of each process that is still running, enter a pkill -15 command to kill the process. For example:

pkill -15 9875

Enter each ps command again to make sure that all Calendar Server processes are stopped.

If a Calendar Server process is still running, enter a pkill -9 command to kill it. For example:

pkill -9 9875



Caution	After you have stopped all Calendar Server processes and before you restart Calendar Server, consider running the csdb utility check command to check for any calendar database corruption that might have occurred. For information about the check command, see Checking and Rebuilding a Calendar Database.

Managing the Group Scheduling Engine Queue

The Group Scheduling Engine (GSE) keeps a queue of events that will be used to update the component database. An administrator can change the timeout value to adjust the time between Calendar Server scans of the queue. Events in the queue can also be listed and specific events deleted if necessary.

About GSE

The GSE allows a Calendar Server user to create events and invite other attendees. If an attendee is on the same Calendar Server, the event is scheduled in the attendee’s calendar. If an attendee is not on the same Calendar Server, the invitation is sent via email. The attendee can then accept or decline the invitation and the GSE will update the event with the reply.

About the GSE Queue

The GSE queue is in reality a separate database managed by the GSE. Calendar Server scans the queue for updates that need to be made to the components database.

You can tune Calendar Server by adjusting the frequency of this scan. This is accomplished by changing the timeout value of gse.belowthresholdtimeout in the ics.conf file. See Chapter 19, "Tuning Calender Server Performance".

The GSE queue entries can be managed (listed and deleted) using csschedule. You must run csschedule on the local machine where Calendar Server is installed.

Listing Entries in the GSE Queue

To list entries in the GSE queue, use the csschedule utility list command. For example, to list all entries in the GSE queue:

To list all entries in the GSE queue for a calendar with the calid Holiday_Schedule:

Deleting Entries in the GSE Queue

To delete entries in the GSE queue, use the csschedule utility delete command. For example, to delete all entries in the GSE queue:

To delete the entry in the GSE queue for calendar calA with the first schedule time of 13:30:45 on 11/30/2001, an offset number of 1, the unique identifier 1111, the recurrence ID 0, and the sequence number 0:

Monitoring Calendar Server

To monitor Calendar Server activity, use the csmonitor, csstats, and cstool utilities. This section describes the following tasks:

Listing Counter Statistics

The csstats utility displays statistical information from counter objects defined in the calendar configuration (counter.conf) files. Counter objects such as httpstat, authstat, wcapstat, or dbstat show information about Calendar Server including:

To list statistical information:

To list statistical information, use the csstats utility list command. For example, to display basic information about the counter objects and the types available:

To list statistics specifically about the httpstat counter object:

To list statistics about the wcapstat counter object:

In this example, set the frequency as every 10 seconds with a duration of one hour.

Monitoring Calendar Server Log Files

Each Calendar Server service writes status information to its own log file. Each log file is named after its associated service name, as shown in Table 10-1:

Table 10-1 Calendar Server Log Files
Service Name	Log File Name
Administration Service (csadmind)	admin.log
Distributed Database Service (csdwpd)	dwp.log
HTTP Service (cshttpd)	http.log
Notification Service (csnotifyd)	notify.log
Single Sign-on log	am_sso.log
Log of start commands	start.log
Log of stop commands	stop.log

Calendar Server log files are stored in the following default directory on Solaris Operating Systems:

Each log file is rolled-over to a new log file with a new name based on the configured time and size limits as follows:

Log Event Severity Levels

Calendar Server provides eight levels of severity for events reported to the log files as described in Table 10-2.

Table 10-2 Calendar Server Log Error Severity Levels
Severity Level	Meaning
CRITICAL	Critical condition.
ERROR	Error condition.
WARNING	Warning condition.
NOTICE	Normal, but signification condition. This is the default reporting level for each calendar service.
INFORMATION	Informational.
DEBUG	Debug-level message.

A log event is represented by a single line that shows the associated timestamp, server host name, severity level, process name (process ID), type of event, priority, and description. You can specify the level of severity of the events that Calendar Server reports to the log files by modifying certain configuration settings in the ics.conf file. For information, see Calendar Log Information Configuration.

You should inspect the log files on a regular basis for EMERGENCY, ALERT, CRITICAL, ERROR, and WARNING level errors and, if found, examine the events for possible problems with the operation of Calendar Server. The NOTICE and INFORMATION level log events are generated during normal operation of Calendar Server and are provided to help you monitor server activity.


Note	When requesting technical support for Calendar Server, you might be asked to provide the log files for help in resolving problems.

Pinging Calendar Server

To verify that a Calendar Server service is listening on a specified port number, use the cstool utility ping command. Pinging a service does not verify that a service is actually running but indicates if it can accept a socket connection.

http – HTTP Service (cshttpd)

admin – Administration Service (csadmind)

ens – Event Notification Service (enpd)



Note	In the current release, you cannot ping the DWP service (csdwpd), or Notification Service (csnotifyd).

For example, to ping the machine with the host name calserver to see if the cshttpd service is listening on port 80:

By default, cstool waits 120 seconds for a response; however, you can change by value by using the -t timeout option.

Refreshing the Calendar Server Configuration

In the current release, do not use the cstool refresh command to refresh a configuration. Instead, use the stop-cal and start-cal commands. For more information, see Starting and Stopping Calendar Server.

Turning Off the Old Calendar Express UI

If you have installed the new Communications Express UI, it is not necessary to turn off the old Calendar Express UI. However, if you want to turn off the old Calendar Express UI, it can be done by renaming the following file: default.html.

The default.html file can be found under the following directory:
/opt/SUNWics5/cal/html

Previous Contents Index Next
Sun Java System Calendar Server Administration Guide