Question:

Stack traces are sometimes requested by Centrify Support for diagnostics. How are these traces collected? Is there any reason why just the core files cannot be used? 


Answer:

Gdb or dbx are not strictly required - but they help. Centrify's adclient does not need it to operate. 

Reasons for requesting stack traces (Where applicable):

If the adclient crashed and generated a core file, adinfo will automatically pick it up and try to generate a stack trace for analysis. 
 

It will skip over this if it cannot find gdb/dbx/adb installed on the machine. 

On all *nix platforms, core analysis is a big problem. It must be analyzed in the exact matching environment/platform, with all the correct versions of various executables/libraries to generate meaningful stack trace for analysis. So when a core file is sent in, the exact a matching environment must be created in order to open the core file for analysis - this may not be feasible as this include the following factors:

- Hardware
- All the (3rd party) libraries
- All the libraries must match the same level as the source environment

Therefore, it is always easier to analyze it on the problem system. Please contact the system vendor for more detailed instructions on how to get gdb or mdb installed.

====== For gdb ======

Run gdb from the shell prompt:

#gdb /usr/sbin/adclient path_name_of_core_file

where path_name_of_core_file is ALWAYS /var/centrifydc/core.year-day-Month-day:hour:minute

When gdb prompts, enter the commands:

set logging on
set pagination 0
info threads
thread apply all bt full
quit

When entering set logging on, gdb will tell the name of the log file, the default is: gdb.txt

====== For dbx ======

Run dbx from the shell prompt:

# dbx /usr/sbin/adclient full_path_to_core_file

When dbx prompts, enter the commands: 

thread
where thread all

If "where thread all" is not supported, type thread to give a list of all the threads:

(dbx) thread

Repeat the steps below for each thread: 

(dbx) thread current <thread number>
(dbx) where
(Repeat this for each thread)
quit

====== For mdb ======

Run mdb from the shell prompt:

mdb /usr/sbin/adclient full_path_to_core_file

When mdb prompts, enter the commands:

$>/tmp/mdb.out
$G
::walk thread | ::findstack 
::status
::quit

Send in the file at /tmp/mdb.out

===== pstack instructions (solaris) =======

https://docs.oracle.com/cd/E19424-01/820-4814/gegyr/index.html

(Link provided as a courtesy)

Note:

adclient.dumpcore

This configuration parameter in /etc/centrifydc/centrifydc.conf specifies whether the Centrify DirectControl Agent should be allowed to dump core.

In most cases, this configuration parameter is set using the following GP:

Computer Configuration / Centrify Settings / DirectControl Settings / Adclient Settings / Configure dump core setting 

Enable and choose to generate a core dump once, always, or never. 

This can also be set manually in the configuration file.The value set for this parameter overrides the default ulimit setting. The parameter value must be one of the following valid options:

1) Never: Centrify DirectControl Agent should never dump core.

2) Once: Centrify DirectControl Agent should dump core only on the first crash after the service starts up.

3) Always: Centrify DirectControl Agent dump core on every crash.

Example:

adclient.dumpcore: never

Additional reading:

https://blogs.oracle.com/dbx/entry/gdb_vs_dbx_commands_mapping