This chapter describes how to approach troubleshooting problems in Directory Server Enterprise Edition. It includes the following sections:
Before you begin troubleshooting a problem, you must first define the scope of your problem. When defining the scope , you need to identify what is working and what is not working. Sometimes it is useful to identify another machine that is working as you expect. Comparing the server that is experiencing a problem with a server that is working correctly simplifies troubleshooting and can help you arrive at a solution more quickly.
For example, you are checking email at work and are suddenly unable to read or write new email. If you can not resolve the problem quickly, you might go to a colleague and see if they are experiencing the same problem. If your colleague is experiencing the same problem, you feel relieved and decide that the problem is a bigger network issue. If your colleague says no, email is working as expected, you might look at your colleague's proxy settings and see if yours are configured the same.
You can help define the scope of your problem by asking questions about what is working and what isn't working, such as the following:
On which servers is the problem being observed?
On which servers is the problem not being observed?
For which types of operations is the problem occurring?
For which types of operations is the problem not occurring?
On the failing server, which plug-ins or components are experiencing the problem? For example, replicated updates, local updates, UID uniqueness, ACIs, roles, CoS, password policy, or all of the above.
On the failing server, which plug-ins or components are not experiencing the problem?
Is the problem permanent or transient?
Where could the problem be permanent or transient, but is not?
Is the problem still growing, decreasing or stable?
Where could the problem be growing but is not?
On each of the servers where the problem is observed, determine the first time the problem was observed, including the date and time. Identify any changes that were made to your system immediately before this date, such as changes to the configuration, upgrades, and installations.
No matter the type of problem you are encountering, there is a minimum set of data that needs to be collected and, if necessary, provided to Oracle Support. If your problem occurs across your topology, you need to provide this generic data for all instances of Directory Server or Directory Proxy Server inside the topology.
The generic data for Directory Server that you collect must include the following:
Collect the Directory Server version information:
# install-path/bin/dsadm --version
Collect the Directory Server access and errors logs that contain the time since the problem started. By default, you find these logs in the following locations:
Provide information about the computers involved, including their IP addresses, operating system version, disk partitions, swap space, installed patches, hard disk space, and file systems used.
Collect the Directory Server configuration file, instance-dir/config/dse.ldif.
For more information about generic data, collection, refer to To Collect Required Debug Data For Any Directory Server Problem in Sun Gathering Debug Data for Sun Java System Directory Server 5.
The generic data for Directory Proxy Server includes the following information:
Collect the Directory Proxy Server version information:
# install-path/bin/dpadm --version
Collect the Directory Proxy Server access and errors logs that contain the time since the problem started. By default, you find these logs in the following locations:
Collect the Directory Proxy Server configuration file using the dpconf info command.
Several tools are available that you can use to collect general information for troubleshooting purposes. This section provides information about the following troubleshooting tools:
The idsktune command provides information about system parameters and tuning recommendations. You can use the output of this command to detect problems in thread libraries or patches that are missing. For more information about the idsktune command, see idsktune(1M)
Run the idsktune command as follows:
The idsktune command is delivered with zip distribution software only.
You can download this script from http://www.sun.com/bigadmin/scripts/indexSjs.html. This script retrieves the correct version of the binary of the running process or from the core and works with 32–bit and 64–bit libraries.
The Solaris pkgapp script packages an executable and all of its shared libraries into one compressed tar file. You provide the process ID of the application and, optionally, the name of the core file to be opened.
The files are stripped of their directory paths, and are stored under a relative directory named /app with their names only, allowing them to be unpacked in one directory. On Solaris 9 and Solaris 10, the list of files output by the pkgapp script is derived from the core file rather than the process image, if it is specified. You must still provide the process ID of the running application to assist in path resolution.
As superuser, run the pkgapp script as follows:
# pkgapp server-pid core-file
You can also run the pkgapp script without a core file. This reduces the size of the pkgapp output. You need to later set the variable to the correct location of the core file.
The dirtracer tool is a shell script that gathers debugging information about a running, hung, or stopped Directory Server process. This information can be used by Oracle Support to diagnose a problem. The scripts collect information about the operating system configuration, the Directory Server configuration, and the runtime data elements, as well as log files, databases, cores, gcores, and pstack output. The type of information gathered depends upon the type of problem you are experiencing.
The dirtracer script is available from BigAdmin at http://www.sun.com/bigadmin/scripts/indexSjs.html.
As superuser, run the dirtracer script as follows:
#./dirtracer -f ./dirtracer.config
The dirtracer.config file contains the configuration parameters used by the dirtracer script to generate its output. The dirtracer script comes with a tool to generate this configuration file called the configurator. This interactive shell script automatically creates a configuration file that addresses the type of problem you are experiencing. The configurator set the parameters for log gathering, core collection, as well as many other parameters.
If you are an Oracle Service Plan customer, you have access to a number of exclusive online resources, including the following:
Oracle support web site
Search the knowledge base for information that corresponds to the problem you are experiencing or use the resources available to you in the Online Support Center, including submitting a new service request.
The GDD tools provide best practices to help you gather the required debug data needed for further problem analysis.
Get patches, diagnostic tools, and software updates from the Update Connection.
Provides access to Security Alerts, Solaris Fingerprint Database, Security T-Patches, and more.
You can browse the forums as a guest or log in and post your own questions.
Find helpful system administration resources, join and discuss issues with other system administrators worldwide.
For questions regarding your Service Plan, contact your local Oracle sales representative.