Some users may experience issues accessing the case portal. For more information, please click here.

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Known Issue: Inventory gathering process may terminate on Unix-like operating systems while gathering Java version details (IOJ-2241253)

Known Issue: Inventory gathering process may terminate on Unix-like operating systems while gathering Java version details (IOJ-2241253)


Inventory gathering ndtrack processes on Unix-like operating systems may terminate unexpectedly while attempting to gather Java version details if the output from a "java" executable is atypical.


When this issue occurs, ndtrack processes will terminate with a segmentation fault and output in the tracker.log file from the ndtrack process will stop after logging that looks like either of the following:

[Wed 05 Jan 2022 10:05:28 AM -03 (G, 0)] {17500} The file '/usr/java/jre7/bin/java' has been detected as a possible package registry
[Wed 05 Jan 2022 10:05:41 AM -03 (G, 0)] {17500} IBM MQ inventory was unsuccessful either because it is not installed or there was an error.


[Wed 05 Jan 2022 10:05:28 AM -03 (G, 0)] {17500} The file '/usr/java/jre7/bin/java' has been detected as a possible package registry
[Wed 05 Jan 2022 10:05:41 AM -03 (G, 0)] {17500} Java product: "Java(TM) SE Runtime Environment", full version: "8.1.037", publisher: "", install location: "/usr/java/jre8/bin".


This issue is caused by a failure by the ndtrack process to handle atypical output from the following command using a java executable file found somewhere on the filesystem:

java -fullversion

Output from this command typically includes version information. An example is:

java full version "1.8.0_20-b26"

If output from a java executable file found on the filesystem is substantially different in form from the above then this issue may occur.

In particular, log message(s) in the tracker.log file stating:

The file '<path>/java' has been detected as a possible package registry

will identify a <path> that does not appear in a subsequent log message:

Java project: <details...>

One of the java executables thus identified will be triggering this issue.


Various tracker (ndtrack) component preferences can be set to stop the inventory gathering process from performing the problematic operation (with the tradeoff that it will limit the inventory data that is gathered):

  1. Set the JavaFullVersion preference to false to disable gathering full Java version details using the "-fullversion" command line option. (Partial version details will still be gathered using the "-version" command line option.)
  2. Set the PerformJavaScan preference to false to disable gathering all Java version details.
  3. Set preferences related to filesystem scanning to limit file scanning to avoid finding the problematic java executable file. For example, set the ExcludeDirectory preference to the directory path containing the java file.

Additional information

Also see the following known issue which has similar symptoms but a different root cause: Inventory gathering may hang on Unix-like operating systems if executable bit is set on a non executable file named "java" (IOJ-2072459)

Fix status

This issue has been fixed in the following FlexNet Manager Suite releases: 2021 R1.4 / Mar 2022 (Cloud), 2022 R1 (On Premises)

Other information

Affected components: Agent, Inventory

Master issue ID: IOJ-2241253

Also known as: FNML-75025

Labels (1)
Was this article helpful? Yes No

Tip: If you have been impacted by this issue, please click the KUDOS button above. This helps to track the relative significance and importance of issues. Clicking on an option against "Was this article helpful?" also helps assess and improve the usefulness of content.

100% helpful (1/1)

Setting the JavaFullVersion=false fixed the issue for me! Thank you


Thanks for the info. Where do you set the setting JavaFullVersion=false.

@FrediG - agent preferences (such as JavaFullVersion) are persistently stored on Unix-like operating systems in the /var/opt/managesoft/etc/config.ini file (see documentation here and here). Best practice is to update this file using the mgsconfig command line tool. For example:

cat <<EOF >/tmp/tempconfig.ini

/opt/managesoft/bin/mgsconfig -i /tmp/tempconfig.ini

If you are invoking ndtrack manually, preferences can also be set on the command line. For example:

/var/opt/managesoft/bin/ndtrack -t Machine -o JavaFullVersion=false


Hi Chris,

Thanks for the feedback. Will there be a way for me to get this deployed in my whole environment, except for logging in to each server and update the confi.ini.

I have a large Linux environment where I experiencing this issue.


@FrediG - If you are using FlexNet Manager Suite On-premises (not Flexera One ITAM) and are comfortable with "advanced" mechanisms then you could try an approach like is described in the following post for setting details in the compliance database that will flow through to the agent policy: Finding installations of Apache Log4j (or other) files on computers with FlexNet Manager Suite.

See the SQL script on that page following the text "Set the value through agent policy settings". Instead of the key name "CTrackerIncludeFile" as shown in that example script, use "CTrackerJavaFullVersion".

@FrediG - You can use a system management tool such as Puppet or Ansible to run the command described by Chris on your Linux servers to update the Config.ini file

Hi Chris,

I used your "advanced" mechanisms and some unix servers could successfully get the agent policy update on config.ini and some didn't (no error was found in policy.log). How to troubleshoot those devices not getting JavaFullVersion update in the config.ini ?


@Woo_Lam - the data flows through several steps and it can be a bit tedious to follow it all the way through. But a starting point may be to check in the agent's installation.log file to ensure that it has recently downloaded a current client settings .osd file to apply, and then manually download the associated client settings .ndc file from the beacon to check that it contains the expected setting.

Hi Chris

I found the problem. I applied the followings on a specific Target that created only for those servers with JavaFullVersion issue to be fixed, but the policy was gone after some days (when I ran "select * FROM dbo.BeaconTargetPropertyValue WHERE KeyName = 'CTrackerJavaFullVersion'​", it returned NULL value). Just wanted to know will it work on a specific Target instead of those 3  Target names that you specified in you SQL script?

-- The value of @TargetName should be set to one 'Target__windows',
-- 'Target__osx' or 'Target__unix' to set policy settings for computers
-- running the identified type of operating system.
-- To target multiple types of operating systems, change the value and
-- re-run this script multiple times.

SET @TargetName = 'Unix Servers turn off Java Full Version'

-- Ensure the built-in target exists
EXEC dbo.BeaconTargetPutByNameInternal
@Name = @TargetName,
@Internal = 0,
@Description = NULL,
@Visible = 1

-- Get the ID of the target to have settings applied

SELECT @btid = BeaconTargetID
FROM dbo.BeaconTarget
WHERE Name = @TargetName

-- Add setting to agent policy for computers covered by the above target
EXEC dbo.BeaconTargetPropertyValuePutByKeyNameBeaconTargetID
@KeyName = 'CTrackerJavaFullVersion',
@BeaconTargetID = @btid,
@Value = 'False'

-- Force beacons to update to get latest settings containing the above changes
EXEC dbo.BeaconPolicyUpdateRevision​

@Woo_Lam - I'm not sure what to expect here sorry - I haven't tried configuring a setting against a target that has been manually configured in the UI. I'm wildly guessing, but maybe custom settings like this will get deleted when the target is edited in the UI.

Hi Chris

Thanks for your response. Is it possible that I can put the server name in the table that manage the servers in the targets instead of updating the target in the UI? Can you find out the table name for me?



@Woo_Lam - I'm not aware of any script published for editing target information directly in the database. There is a little discussion about this in the following thread: Targets in Discovery & Inventory Rules

And here is a related idea that you may consider voting for: FNMS-I-234: Bulk Load vCenter Target IP's into DB & Providing a feature to add target vCenter IPs in numerical order or by sort Feature

Hi Chris

Thanks for the info you provided here.



Version history
Last update:
‎Jun 12, 2022 03:49 AM
Updated by: