Symptoms

Core dump files are generated from java processes executed on Unix-like operating systems while an ndtrack process is gathering inventory. Core dump files are often stored somewhere under the /opt/managesoft directory structure.

Cause

While gathering inventory, ndtrack processes may run java executables found on the filesystem to gather version and other details about Java installations.

This issue can occur if a Java installation on a device is in a broken state, causing it to crash and generate a core dump when executed.

Diagnosis steps

This problem can be confirmed and diagnosed by seeking to identify the specific java executable and command line arguments that has crashed.

You may be able to identify this by inspecting details in crash dump files. Details of how to do this will vary by operating system, but if there is a Javacore*.txt file generated by the crash it may contain details like the following which identify the command line used:

1CICMDLINE     <path>/java -version 

Some versions of ndtrack generate logging which helps to identify the problematic java executable and command lines. Here is an example to illustrate how this logging may appear in a tracker.log file:

[2025-08-12T12:03:26EST (G, 0)] {17394273} Failed to run java binary '/usr/jdk-11.0.16+8/bin/java' with parameters '-version', command execution failed: ErrorCode=0xe1ac0003, ExitCode=9
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'openjdk version "11.0.16" 2022-07-19'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'IBM Semeru Runtime Open Edition 11.0.16.0 (build 11.0.16+8)'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'Eclipse OpenJ9 VM 11.0.16.0 (build openj9-0.33.0, JRE 11 AIX ppc64-64-Bit Compressed References 20220804_431 (JIT enabled, AOT enabled)'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'OpenJ9   - 04a55b45b'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'OMR      - b58aa2708'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'JCL      - ab74d97849 based on jdk-11.0.16+8)'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'libc++abi: terminating'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'JVMDUMP039I Processing dump event "abort", detail "" at 2025/08/12 12:02:20 - please wait.'
[2025-08-12T12:03:26EST (G, 0)] {17394273} ERR> 'JVMDUMP032I JVM requested System dump using '/opt/managesoft/core.20250812.120220.49353140.0001.dmp' in response to an event'

Additional diagnostic information about how java processes have been executed may also be available in diagnostic tracking generated by ndtrack processes. See the following article for information about how to enable diagnostic tracing: Gathering diagnostic tracing from a FlexNet inventory agent process on Unix-like operating systems.

Remediation

The preferred way to remediate this problem is to correct the problematic Java installation so that it no longer crashes. This may require working with teams supporting affected devices to identify and fix the reason for the crash.

Alternatively, you may consider configuring ndtrack so that it does not scan the directory containing the problematic Java installation, or does not gather Java installation details at all. This will avoid running the problematic java executable, thus avoiding the crash behavior. 

For example, consider the following settings that could be used to control these aspects:

• Directories to scan during inventory gathering can be configured in the File Evidence section of the Inventory Settings page.
• The following agent preferences control whether Java details are gathered: PerformJavaScan, PerformOracleJavaAuditScan.