Contained Within
Find More DocumentationFeatured Support Resources |  PDF로 이 문서 다운로드 (537 KB)
Chapter 1 Sun Gathering Debug Data for Sun Java System Directory ServerThis technical note describes how to use SunTM Gathering Debug Data (Sun GDD or GDD) to collect data that the Sun Support Center requires in order to debug problems with Sun JavaTM System Directory Server software. By collecting this data before you open a Service Request, you can reduce substantially the time needed to analyze and resolve the problem. For more information on how this document and associated scripts can help you in better dealing with Directory Server problems, see: http://www.sun.com/services/gdd/index.html This document is intended for anyone who needs to open a Service Request about Directory Server software with the Sun Support Center. This technical note contains the following sections: 1.1 Technical Note Revision History
1.2 About This Technical NoteThis document covers Sun Java System Directory Server 5 on all supported platforms. You can use this document in all types of environments, including test, pre-production, and production. Verbose debugging is not used so as to avoid performance impact, except when it is deemed necessary. In some cases, it is possible that the problem could disappear when you configure logging for debug mode. However, this is the minimum to understand the problem. In the majority of cases, the debug data described in this document is sufficient to analyze the problem. This document does not provide workarounds nor techniques or tools to analyze debug data. It provides some troubleshooting, but you should not use this guide as an approach to troubleshooting Directory Server problems. If your problem does not conveniently fit into any of the specific categories, supply the general information described in To Collect Required Debug Data For Any Directory Server Problem and clearly explain your problem. If the information you initially provide is not sufficient to find the root cause of the problem, Sun will ask for more details, as needed. 1.2.1 Prerequisites for Collecting Directory Server Debug DataThe prerequisites for collecting debug data for Directory Server are as follows.
1.2.2 Variables Used in This Technical NoteThe following describes the variables used in the procedures in this document. Gather the values of the variables if you don't already know them before you try to do the procedures.
Many paths specified in this document use the forward slash format of UNIX. If you are running software on a Windows system, use the equivalent backslash format. 1.3 Overview of Collecting Debug Data For Directory Server
Collecting debug data for any Directory Server problem involves these basic operations: 1.4 Creating a Service Request with the Sun Support CenterWhen you create a Service Request with the Sun Support Center, either online or by phone, provide the following information:
Upload your debug data archive file to one of the following locations: Note – When opening a Service Request by phone with the Sun Support Center, provide a summary of the problem. Also provide the details in a text file named Description.txt. Be sure to include Description.txt in the archive along with the rest of your debug data. For more information on how to upload files, see: http://supportfiles.sun.com/show?target=faq 1.5 What Directory Server Debug Data Should You Collect?This section describes the kinds of debug data you need to provide based on the problem you are experiencing. This section contains the following tasks:
|
$ ldapmodify -h host -p port -D "cn=Directory Manager" -w password dn: cn=config changetype: modify replace: nsslapd-infolog-area # nsslapd-errorlog-level in 5.1 nsslapd-infolog-area: 8192 |
To return to the default log level, use the following command.
$ ldapmodify -h host -p port -D "cn=Directory Manager" -w password dn: cn=config changetype: modify replace: nsslapd-infolog-area # nsslapd-errorlog-level in 5.1 nsslapd-infolog-area: 0 |
You must restart Directory Server for the change to take effect.
Provide a listing of the changelog directory.
- UNIX and Linux
-
ls -la changelog-dir
- Windows
-
dir changelog-dir
If you cannot find the change log, examine the Directory Server configuration file, server-root/slapd-serverID/config/dse.ldif, to find the path. The path is specified as the values of attribute nsslapd-changelogdir.
Collect output from the insync command.
The insync command indicates the state of synchronization between a master replica and one or more consumer replicas. The following command shows the state over a period of 30 seconds.
server-root/shared/bin/insync -s "cn=Directory Manager:password@hostname1:ldap-port" -c "cn=Directory Manager:password@hostname2:ldap-port" 30
Collect output from the repldisc command.
The repldisc command displays the replication topology, building a graph of all known replica, then showing the result as a matrix.
server-root/shared/bin/repldisc -D "cn=Directory Manager" -w password -b base-dn -s host:ldap-port
Here, base-dn is the DN of the replicated suffix.
To Collect Required Debug Data
For Directory Server Schema Problems
This procedure describes what data to collect when experiencing Directory Server schema violation errors.
-
Collect a copy of the schema folder, server-root/slapd-serverID/config/schema, and all the files in the folder.
-
Indicate whether you have the same problem both in the Console and on the command line.
-
Provide a list of the last changes made to the schema files.
-
If the schema violation occurred during an add, modify, delete, or replace operation, provide an LDIF representation of the changes and a list of the commands used.
1.6 Configuring the Operating System to Generate Core Files
Core files and crash dumps are generated when a process or application terminates abnormally. You can also generate core files and crash dumps to help diagnose why a process does not respond to client application requests.
This section includes the following procedures:
To Configure Solaris OS to Generate Core
Files
This procedure shows you how to use the coreadm command to configure the system so that all process core files are placed in a single system directory. This means it is easier to track problems by examining core files in a specific directory whenever a Solaris OS process or daemon terminates abnormally.
Before You Begin
Make sure that the /var file system where the core files are generated has sufficient space. Once you configure Solaris OS to generate core files as shown here, all processes that crash write a core file to the /var/cores directory.
-
Run the following commands as root.
mkdir -p /var/cores coreadm -g /var/cores/%f.%n.%p.%t.core -e global -e global-setid -e log -d process -d proc-setid
In this command:
- -g
-
Specifies the global core file name pattern. Unless a per-process pattern or setting overrides it, core files are stored in the specified directory with a name such as program.node.pid.time.core, for example: mytest.myhost.1234.1102010309.core.
- -e
-
Specifies options to enable. The preceding command enables:
-
Use of the global (that is, system-wide) core file name pattern (and thereby location)
-
Capability of setuid programs to also dump core as per the same pattern
-
Generation of a syslog message by any attempt to dump core (successful or not)
-
- -d
-
Specifies options to disable. The preceding command disables:
-
Core dumps per the per-process core file pattern
-
Per-process core dumps of setuid programs
-
The preceding command stores all core dumps in a central location with names identifying what process dumped core and when. These changes only impact processes started after you run the coreadm command. Use the coreadm -u command after the preceding command to apply the settings to all existing processes.
-
Display the core configuration.
# coreadmglobal core file pattern: /var/cores/%f.%n.%p.%t.core init core file pattern: core global core dumps: enabled per-process core dumps: disabled global setid core dumps: enabled per-process setid core dumps: disabled global core dump logging: enabledSee the coreadm man page for further information.
-
Set the file size as large as possible, using the ulimit command.
# ulimit -c unlimited # ulimit -a coredump(blocks) unlimitedSee the ulimit(1) man page for details.
-
Verify that applications can in fact generate core files.
# cd /var/cores # sleep 100000 & [1] pid # kill -8 pid # ls
You should see a core file for the sleep process you killed.
To Configure Red Hat Linux to Generate Core
Files
On Red Hat systems, you can enable core files to be generated on a per user basis.
-
Open the ~/.bash_profile file for the server user in a text editor.
-
Search for a line using the ulimit command as follows.
ulimit -S -c 0 > /dev/null 2>&1
-
Either comment out the line, or set your own limit for core file size.
To Configure Windows to Generate Crash
Dumps
The native debug tool on Windows systems, Dr. Watson, allows you to generate crash dumps.
However, Dr. Watson does not allow generation of crash dumps on a running process. To generate crash dumps from a running process, install the Debugging Tools. The Debugging Tools are freely available from the Windows web site at http://www.microsoft.com/whdc/devtools/debugging/default.mspx.
-
You can use Dr. Watson for crash dumps generated when a process dies.
-
Use the Window Debugging Tools to generate crash dumps of a running process.
-
Enable generation of a crash dump for your application.
Get the process ID of the application using the tlist.exe command, then enable the crash dump.
win-dbg-root\tlist.exe
win-dbg-root\adplus.vbs -crash -FullOnFirst -p pid -o C:\dump-dir
The adplus.vbs command tracks the application with process ID pid. The adplus.vbs command generates a dmp file in the event of a crash.
-
When collecting crash dump information, take the complete folder generated under C:\dump-dir.
To Run the pkg_app Script
The pkg_app script packages an executable and all of its shared libraries into one compressed tar file given 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 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.
Two scripts are created to facilitate opening the core file when the tar file is unpacked.
-
opencore. This is the script to be executed once unpacked. It sets the name of the core file and the linker path to use the app/ directory, and then invokes dbx with the dbxrc file as the argument.
-
dbxrc. This script contains the dbx initialization commands to open the core file.
-
Copy the script to a temporary directory on the system where the server is installed.
-
Become superuser.
-
Run the pkg_app script in one of the following ways.
1.7 Reporting Problems
Use the following email aliases to report problems with this document and its associated scripts:
- gdd-feedback@sun.com
-
For feedback on this document
- gdd-issue-tracker@sun.com
-
To report problems in gathering debug data
1.8 Documentation, Support, and Training
The Sun web site provides information about the following additional resources:
-
Documentation (http://www.sun.com/documentation/)
-
Support (http://www.sun.com/support/)
-
Training (http://www.sun.com/training/)
1.9 Third-Party Web Site References
Third-party URLs are referenced in this document and provide additional, related information.
Note –
Sun is not responsible for the availability of third-party web sites mentioned in this document. Sun does not endorse and is not responsible or liable for any content, advertising, products, or other materials that are available on or through such sites or resources. Sun will not be responsible or liable for any actual or alleged damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods, or services that are available on or through such sites or resources.
1.10 Searching Sun Product Documentation
Besides searching for Sun product documentation from the docs.sun.com web site, you can use a search engine of your choice by typing the following syntax in the search field:
search-term site:docs.sun.com
For example, to search for Directory Server, type the following:
"Directory Server" site:docs.sun.com
To include other Sun web sites in your search, such as java.sun.com, www.sun.com, and developers.sun.com, use sun.com in place of docs.sun.com in the search field.
1.11 Sun Welcomes Your Comments
Sun is interested in improving its documentation and welcomes your comments and suggestions. To share your comments, go to http://docs.sun.com and click Send Comments. In the online form, provide the full document title and part number. The part number is a 7-digit or 9-digit number that can be found on the book's title page or in the document's URL. For example, the part number of this book is 820-0437-10.