Sun Java System Calendar Server 6 2005Q4 Administration Guide

Troubleshooting Calendar Server

This section covers various troubleshooting ideas for non-database problems. The following topics are covered in this section:

Tip –

In addition, there is a trouble shooting section for SSL in the SSL chapter:

Troubleshooting SSL

Pinging a Calendar Service

To verify that a 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.

Service Options for cstool

The Calendar Server service options are:


HTTP Service (cshttpd)


Administration Service (csadmind)


Event Notification Service (enpd)

Note –

You cannot ping the DWP service (csdwpd), or Notification Service (csnotifyd).

cstool Example

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

cstool -p 80 -h calserver ping http

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

For the complete utility reference material, refer to Appendix D, Calendar Server Command-Line Utilities Reference.

Note –

To run cstool, Calendar Server must be running.

ProcedureFixing start-cal Problems

If not all of the calendar services started when you issued start-cal, the ones that did start must be stopped before restarting. For example, if enpd, csnotifyd, and csadmind started, but not cshttpd, then enpd, csnotifyd, and csadmind must be stopped.

To start calendar services:

  1. Log in as a user who has administrative rights to the system where Calendar Server is running.

  2. Use start-cal to stop and then restart services. For example:


    start-cal issues a stop-cal command first before starting the various calendar services.

  3. If stop-cal fails to stop, there might be some child processes that failed to stop. To handle this, see Fixing stop-cal Problems.

Fixing stop-cal Problems

There are two separate issues to consider when Calendar Server shuts down:

ProcedureTo Stop Child Processes

After issuing stop-cal, it is possible that some child processes were not stopped. 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 individually, using the following procedure:

  1. Log in as a user who has administrative rights to the system where Calendar Server is running.

  2. 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
  3. Using the PID of each process that is still running, enter a kill -15 command to kill the process. For example: kill -15 9875

  4. 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 kill -9 command to kill it. 
    For example: kill -9 9875

    Note –

    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.

ProcedureTo Recover After an Improper Shutdown

If Calendar Server was not properly shutdown, perform the following steps:

  1. Perform the steps in the previous procedure, Fixing stop-cal Problems.

  2. Manually delete all files in the LDAP data cache database directory.

    These left over files could cause database corruptions. To delete the files:

    1. Change to the LDAP data cache directory.

      The default is /opt/SUNWics5/csdb/ldap_cache, but use the directory pointed to by the local.ldap.cache.homedir.path parameter in the ics.conf file.

    2. Remove all files in the directory.

      For example: rm *.*

    3. Check to make sure all files were removed.

      For example: ls

  3. Restart Calendar Server.


    For instructions on how to configure LDAP data caching, see Configuring Calendar Server for LDAP. For more information about the LDAP data cache, see theSun Java System Communications Services 6 2005Q4 Deployment Planning Guide.

Can't Connect to Back-end Server

  1. Ping the back-end server to see if it is responding.

    If it is responding, go to step 3. If it is not responding, determine why it is failing, and when it is functioning again, proceed to

  2. Clear the CLD cache. See Clearing the CLD Cache.

    If you are using the CLD cache option and you have updated a server name for an ics.conf parameter, you should clear the CLD cache to remove the server names. An out-of-date entry in the CLD cache can prevent a front-end server from establishing a connection to the correct back-end server or cause Calendar Server not to find a calendar after it have been moved.

  3. Restart Calendar Server.

Can’t Find Calendar

If you are using the CLD cache option and you have moved one or more calendars to different back-end servers (or changed the name of the back-end server), perform the following steps:

  1. Be sure that you followed the procedure for moving calendars found at:

    Managing User Calendars.

  2. Clear the CLD cache. See Clearing the CLD Cache.

    The CLD cache will be out of date if you moved one or more calendars to different back-end servers. To refresh it, you need to clear the cache so it will be rebuilt.

Get “Unauthorized” When Trying to Log In Using Proxy Authentication

  1. Verify that service.http.allowadminproxy is set to “yes”.

  2. Verify that the admin-user has Calendar Server administrator privileges.

  3. Verify that the admin-password is correct.

  4. Verify that the calendar-user is a valid Calendar Server user.

Troubleshooting Searches that Don’t Complete Properly

The nsslapd-sizelimit and nsLookthroughLimit attributes in your LDAP directory server configuration must be large enough so that searches complete properly. If nsSizeLimit is not large enough, truncation can occur and no results will be displayed. If nsLookthroughLimit is not large enough the search may not complete.

This section covers the following topics:

ProcedureTo Determine if Limit Attributes Have Appropriate Values

  1. To determine if these attributes are set to appropriate values, try the following command:

    ldapsearch -b "base" "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

    where base is the LDAP base DN of the directory server where the user and resource data for Calendar Server is located, and user is the value that an end user can enter in the search dialog in the user interface.

  2. If the LDAP server returns an error, the nsSizeLimit or the nsLookthroughLimit parameters might not be large enough.

ProcedureTo Set the Limit Attributes to Appropriate Values

The DN for these attributes is:

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

  1. Use ldapmodify to dynamically set the value of nsLookthroughLimit.

    You do not have to stop and restart Directory Server to change this attribute.

    The default value is 5000. You might want to increase this value if searches are not reporting results. However, this could slow down the LDAP server.

    It is possible to set the limit to -1, which causes no limit to be used. However, do this with caution as it could conceivably cause the system to hang.

  2. If you want to set nsslapd-sizelimit to a higher value, you must perform the following steps:

    1. Stop the Directory Server.

    2. Edit the dse.ldif file.

    3. Restart the Directory Server.

      Note –

      For information on how to use ldapmodify and edit the dse.ldif file, see Directory Server documentation found at:

Turning Off Those Annoying Daily Messages from csstored

The start-cal command launches the csstored process by default, even if it is unconfigured. An unconfigured csstored process will emit a message stating it is unconfigured, every 24 hours, on every machine where csstored is running.

Disable the message by preventing csstored from running unconfigured. To disable the csstored process from running, set the following ics.conf parameter as shown for each machine where the message is being generated:”no”

Be careful not to disable the process on the machines where you have csstored configured to make automatic backups.