Symantec Access Management

Hi,

We use CA Directory as the IDM's main user store. we have 4 servers with replication enabled. On one of the server the DSA keeps crashing. This happens on a regularly(once in 2 days)

following are the logs captured.

[229] 20160601.104448.972 WARN : LDAP: Unknown attribute type: userPrincipalName

[252] 20160601.104505.540 WARN : Abandoning op 2

[252] 20160601.104505.540 WARN : Op invalid - lost?

[228] 20160601.104505.540 WARN : LDAP: Unknown attribute type: attribute

[212] 20160601.104505.556 WARN : Bind: Credentials not supplied

Here are the event viewer logs.

Faulting application name: dxserver.exe, version: 12.0.9143.0, time stamp: 0x54bcd8d7

Faulting module name: dxserver.exe, version: 12.0.9143.0, time stamp: 0x54bcd8d7

Exception code: 0xc0000005

Fault offset: 0x000000000004b3b4

Faulting process id: 0xa00

Faulting application start time: 0x01d1bb458eb7e73b

Faulting application path: D:\Program Files\CA\Directory\dxserver\bin\dxserver.exe

Faulting module path: D:\Program Files\CA\Directory\dxserver\bin\dxserver.exe

Report Id: 6dc51c04-2807-11e6-9397-005056a73455

We are using CA Directory 12 Sp 14.

Hello,

Please, check the dsa's  servers\dsaname.dxi the value for dxgrid-db-size if is not short.

But since this could be different causes, please, open a support case to be possible share the dxinfo tool results in the case to support review the possible causes of this problem in your environment.

Cheers

Hi Valdo,

dxgrid-db-size is set to 20000;  This is across all the servers.

I will open up a Support case for the same.  If anyone else have some suggestions, please do let me know.

Hi Kevin,

An issue with this same fault offset has been recently reported. Unfortunately, the logs and fault offset don't provide a clue as to the root cause.

If you could raise a support case that would be great. As this is occurring on a regular basis the following will really assist in the investigation of this issue:
* Enabling the query-log so we can check what operations are occurring leading up to the incident.

* Enabling "set trace = all;" and re-initializing the DSA in question or if restarting "set defer-trace = all;" and running until the next crash. This will have a performance impact but might be a worthwhile hit to identify and address the issue. This assumes there is plenty of disk.

There have been a few crash fixes applied since 12.0 SP14 was released, but we haven't seen any issues around this fault offset.

Thanks,

Justin

You should look into trace logs to dig deeper. Increase log level using console mode. You can connect to console mode using following command:

Telnet localhost <console port>

Use following command to increase trace leve

Set trace=all;

Output will be written to trace file.

Please remember this will generate a lot of logging and will fill disk space pretty quick. So remember to decrease the level to warn when you are done.