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 Sun 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/slapd/server/ns-slapd -D instance-dir -V |
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:
instance-dir/logs/access instance-dir/logs/errors |
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, install-path/slapd-serverID/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 includes the generic data collected for Directory Server and the following Directory Proxy Server information:
Collect the Directory Proxy Server version information:
# install-path/bin/dps/server/bin/ldapfwd -v |
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:
instance-dir/logs/ |
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, patch level, 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:
./idsktune |
The idsktune command is delivered next to the dsee_deploy command with zip distribution software only.
The Solaris pkg_app 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.
You can download this script from http://kaneda.central.sun.com/pkg_app/. This script retrieves the correct version of the binary of the running process or from the core and works with 32 and 64 bit libraries.
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 pkg_app 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 pkg_app script as follows:
# pkg_app server-pid core-file |
You can also run the pkg_app script without a core file. This reduces the size of the pkg_app 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 Sun Support to diagnose a problem. The scripts collects 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/.
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 a Sun Service Plan customer, you have access to a number of exclusive online resources, including the following:
Sun support web site
Search the knowledgebase for information that correspond to the problem you are experiencing.
The Sun GDD tools provide best practices to help you gather the required debug data needed for further problem analysis.
If you are a SunSpectrum Support member, you can use the resources available to you in the Online Support Center, including submitting a new service request.
Get patches, diagnostic tools, and software updates from the Sun Update Connection.
Provides access to Security Sun Alerts, Solaris Fingerprint Database, Security T-Patches, and more.
You can browse the forums as a guest or login and post your own questions.
Join the System Admin Community
Find helpful system administration resources, join and discuss issues with other system administrators worldwide.
For questions regarding your Sun Service Plan, contact your local Sun sales representative.