test

Sun Java System Calendar Server 6.3 Administration Guide

22.4 Non-Database Troubleshooting for 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:

7.2 Troubleshooting SSL for Calendar Server 6.3 Software

22.4.1 One cshttpd Process is Accepting Too Many Connections and Taking 100% of CPU Time

If one cshttpd process is accepting too many connections and taking 100% of CPU time, you might have disabled load balancing. To re-enable it, change the value of ics.conf parameter service.http.loadbalancing to "yes".

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 an administrator with configuration privileges.

  2. Issue the stop-cal command.

  3. If the stop-cal command fails to stop all Calendar Server services, there might be some child processes still running. To handle this, see 22.4.2 Fixing stop-cal Problems.

  4. Once you are sure all Calendar Server processes are stopped, use the start-cal command to start all services. For example:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

22.4.2 Fixing stop-cal Problems

This section contains some conceptual information and instructions for 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, 22.4.2 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.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    For instructions on how to configure LDAP data caching, see 4.8 Configuring LDAP for Calendar Server Version 6.3. For more information about the LDAP data cache, see theSun Java Communications Suite 5 Deployment Planning Guide.

22.4.3 Can't Connect to Back-End Server

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

    If it is not responding, determine why it is failing. When it is functioning again, proceed to the next step in this task.

  2. Clear the CLD cache. See 12.5 Clearing the CLD Cache in Calendar Server Version 6.3.

    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. Stop the server with the stop-cal command.

  4. Restart Calendar Server using start-cal.

22.4.4 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), might not be able to see the calendars on the new server.

    If this happens, perform the following steps:

  1. Clear the CLD cache. See 12.5 Clearing the CLD Cache in Calendar Server Version 6.3.

    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.

  2. If that fails, confirm that you followed the correct procedure for moving calendar. This information can be found at:

    15.6 Managing User Calendars.

    Then, clear the cache.

22.4.5 Can't Create Calendar on Back-End Machine

If you try to create a calendar on a designated back-end machine, and you get the following error message: Invalid DWP Host Server, it means one of two things. Either your server is not configured properly, or the calendar owner has already been assigned to a different back-end server.

This section contains information on how to fix these two problems:

22.4.5.1 Back-End Machine Not Configured Properly

Look at the ics.conf file for the back-end server in question.

Verify that the following settings exist: 

service.dwp.enable = "yes"
caldb.cld.type = "directory"
local.hostname = "back-end hostname"

22.4.5.2 Calendar Owner Assigned to a Different Back-End Machine

Look at the user's LDAP entry and see if there is an icsDWPHost attribute present. The value of icsDWPHost must match the back—end server name on which you are attempting to create the calendar. You can not create a calendar for this user on a different back-end server.

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

This section contains suggestions for possible reasons for failure. Follow the suggested steps and retry the login.

  1. Perform one or more of the following steps to fix this error:

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

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

    • Verify that the admin-password is correct.

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

  2. Retry the log in.

22.4.7 Troubleshooting Searches that Don’t Complete Properly

This section contains conceptual information and instructions for 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:

      http://docs.sun.com/coll/1316.1