PingAuthorize Server troubleshooting information

By default, this log file is available at logs/errors below the server install root, and it provides information about warnings, errors, and other significant events that occur within the server. A number of messages are written to this file on startup and shutdown, but while the server is running, there is normally little information written to it. In the event that a problem does occur, the server writes information about that problem to this file.

The following is an example of a message that might be written to the error log:

The category field provides information about the area of the server from which the message was generated. Available categories include:

The severity field provides information about how severe the server considers the problem to be. Available severities include:

The messages written to the error log can be filtered based on their severities in two ways. First, the error log publisher has a default-severity property, which can be used to specify the severity of messages logged regardless of their category. By default, this includes the NOTICE, SEVERE_WARNING, SEVERE_ERROR, and FATAL_ERROR severities.

You can override these severities on a per-category basis using the override-severity property. If this property is used, then each value should consist of a category name followed by an equal sign and a comma-delimited set of severities that should be logged for messages in that category. For example, the following override severity would enable logging at all severity levels in the PROTOCOL category:

Note that for the purposes of this configuration property, any underscores in category or severity names should be replaced with dashes. Also, severities are not inherently hierarchical, so enabling the DEBUG severity for a category will not automatically enable logging at the INFORMATION, MILD_WARNING, or MILD_ERROR severities.

The error log configuration can be altered on the fly using tools like dsconfig, the Administrative Console, or the LDIF connection handler, and changes will take effect immediately. You can configure multiple error logs that are active in the server at the same time, writing to different log files with different configurations. For example, a new error logger can be activated with a different set of default severities to debug a short-term problem, and then that logger can be removed after the problem is resolved, so that the normal error log does not contain any of the more verbose information.

The server.out file holds any information written to standard output or standard error while the server is running. Normally, it includes a number of messages written at startup and shutdown, as well as information about any administrative alerts generated while the server is running. In most cases, this information is also written to the error log. The server.out file can also contain output generated by the JVM. For example, if garbage collection debugging is enabled, or if a stack trace is requested via kill -QUIT as described in a later section, then output is written to this file.

The debug log provides a means of obtaining information that can be used for troubleshooting problems but is not necessary or desirable to have available while the server is functioning normally. As a result, the debug log is disabled by default, but it can be enabled and configured at any time.

Some of the most notable configuration properties for the debug log publisher include:

As with the error and access logs, multiple debug loggers can be active in the server at any time with different configurations and log files to help isolate information that might be relevant to a particular problem. Debug targets can be used to further pare down the set of messages generated. For example, you can specify that the debug logs be generated only within a specific class or package.

The configuration audit log provides a record of any changes made to the server configuration while the server is online. This information is written to the logs/config-audit.log file and provides information about the configuration change in the form that can be used to perform the operation in a non-interactive manner with the dsconfig command. Other information written for each change includes:

In addition to information about the individual changes that are made to the configuration, the server maintains complete copies of all previous configurations. These configurations are provided in the config/archived-configs directory and are gzip-compressed copies of the config/config.ldif file in use before the configuration change was made. The file names contain timestamps that indicate when that configuration was first used.

The setup tool writes a log file providing information about the processing that it performs. By default, this log file is written to logs/setup.log although a different name may be used if a file with that name already exists, because the setup tool has already been run. The full path to the setup log file is provided when the setup tool has completed.

Many of the administrative tools provided with the server (for example, import-ldif, export-ldif, backup, restore, etc.) can take a significant length of time to complete writing information to standard output or standard error (or both) while the tool is running. They also write additional output to files in the logs/tools directory (for example, logs/tools/ import-ldif.log). The information written to these log files can be useful for diagnosing problems encountered while they were running. When running using the server tasks interface, log messages generated while the task is running can alternately be written to the server error log file.