Calendar Server

Recommended Information Gathering for Calendar Server Issues

When contacting Sun Support to obtain assistance with a Calendar Server issue, it is necessary to provide a detailed problem description and a minimum set of required data. Directly below are some guidelines on these topics. It will also often be necessary to collect additional data which is more specific to the problem - recommendations for which will follow in later sections.

General Information

How to check Calendar version

For Calendar 5.x, in /SUNWics5/cal/bin/config/ics.conf.template, look for a line like this:

product.hotfix.version = "5.1.1hf1.22"

For Calendar 6.x on Solaris, get output of "pkgparam -v SUNWics5" (preferred) or "showrev -p | grep SUNWics5".

For Calendar 6.x on Linux, get output of "rpm -q sun-calendar-core".

Required data

Data that is required in most cases:

1. Calendar version.

2. Platform eg Solaris

3. OS version

Solaris: output of "uname -a", "cat /etc/release"

4. Calendar config file ics.conf

Calendar 5.x ics.conf is in <serverroot>/SUNWics5/cal/bin/config/
Calendar 6.x ics.conf is in /etc/opt/SUNWics5/config/

5. Calendar logs.

Default location for logs is /var/opt/SUNWics5/logs

6. Problem description

What issue you are currently seeing?
What has changed on your system if anything?
What time did you notice the issue?
Is it affecting all users or only specific users?

7. If the problem is reproducible, provide test case i.e. steps to reproduce.

Some Common Issues:

Process Crash

1. Which process is crashing?

2. Is there a core dump?

If there is a core gather

3. Core files

4. Output of "file <core>" (tells you which process dumped core)

5. Pkg_app output from the process. See later in this section for more info on pkg_app.

6. Timestamp of each core file ("ls -l <core_file>").

7. ics.conf

8. Logs. Must include the time period of the core dumps. (look at Calendar logs, system logs - for Solaris, /var/adm/messages*)

9. Pstack of each core file, taken on the same box where the crash occurred:

For Calendar 5.x:
# cd <serverroot>/SUNWics5/cal/bin
# pstack <core_file> > /tmp/pstack_core1.out

For Calendar 6.x:
# cd <serverroot>/SUNWics5/cal/lib
# pstack <core_file> > /tmp/pstack_core1.out

Process Hang

1. Which process is hanging?

2. "ps -ef" output (ps -ef > /tmp/ps_ef.out)

3. Pstacks and prstat output (5 consecutive pstacks of each cshttpd process, 10 seconds apart), while the problem is happening.

Sample script to gather pstack and prstat (modify "SERVERROOT" accordingly):#!/bin/sh
i=0
cd SERVERROOT/cal/lib
while [ "$i" -lt "5" ]
do
echo "$i\n"
dateprint=`date "+%y%m%d:%H%M%S"`
prstat -L -p PID 0 1 > /tmp/prstat_L.$dateprint
pstack PID > /tmp/pstack.$dateprint
i=`expr $i + 1`;
sleep 10
done
4. Vmstat, prstat output:# dateprint=`date "+%y%m%d:%H%M%S"`

vmstat 2 20 > /tmp/vmstat.$dateprint &
prstat -c 2 20 > /tmp/vmstat.$dateprint &
5. Truss of the hung process (truss -feald -vall -rall -wall -o truss_cshttpd.out -p PID)

6. Backup of entire csdb directory (cd /var/opt/SUNWics5; tar -cvpf csdb.tar csdb)

7. Db_stat output:

# cd /var/opt/SUNWics5/csdb
# SERVERROOT/cal/tools/unsupported/bin/db_stat -c . > /tmp/db_stat_c.out
# SERVERROOT/cal/tools/unsupported/bin/db_stat -Co . > /tmp/db_stat_Co.out

8. Gcores (3 gcores of the hung process, 30 seconds apart, "gcore -o COREFILE PID")

9. Calendar logs.

10. System logs (e.g. /var/adm/messages*).

11. Calendar version info, ics.conf, OS version.

DB corruption

(csdb check or rebuild crashes or reports corruption, or Calendar admin log reports DB errors).

A copy of the csdb files (default location is "/var/opt/SUNWics5/csdb").
E.g. # tar -cvpf cu_csdb.tar /var/opt/SUNWics5/csdb

About pkg_app script

Works with 32 and 64 bit libraries
Can be run in three different ways, a) pid and corefile, b) pid only, c) corefile only.
Retrieves the correct version of the binary of the running proccess or from the core.
Asks for the customers Sun case number to add to the name of the tar.gz file for easy identification.
Includes Pmonitor which is executed at runtime to gather process resources used.

Usage: pkg_app <pid> <core_file>

"ls -l pkg*.Z", from the directory where the script was run.

Get the file "pkg_app_<process_name>.tar.Z"