Administration Guide › Troubleshooting CA Directory › Collecting Data if a DSA Fails Internal Tests—DXDUMPCORE Environment Variable

Collecting Data if a DSA Fails Internal Tests—DXDUMPCORE Environment Variable

The DSA program contains internal tests ("assertions") that it runs to ensure that the program is running correctly.

If one of these internal tests fails, it means that the DSA is in an unexpected state, and this should not happen. However, it does happen, though rarely.

Normally if an internal test fails, the DSA logs this and continues to run. This behavior ensures that the DSA does not stop, which is what you want when the DSA is used in a production environment. However the log entry might not contain enough information to fully analyze the problem that caused the test to fail.

To collect more information, and so enable a full analysis of the problem, define the environment variable DXDUMPCORE on the DSA host. If DXDUMPCORE is defined and an internal test fails, the DSA writes the contents of the program to a file (sometimes this is called a core dump) and then stops. The file that contains the core dump is in DXHOME and is called:

• core (All systems except Linux)
• core.ProcessId (Linux Systems)

Important! Only define DXDUMPCORE if you are prepared for the DSA to stop if it fails an internal test. Make sure DXDUMPCORE is not defined in production environments, because if it is defined, the DSA is vulnerable to Denial of Service attacks.

If DXDUMPCORE is defined and the DSA fails an internal test, you can send the core dump file (with the DXinfo output) to CA Support for a full analysis of the problem.