A new Flexera Community experience is coming on November 18th, click here for more information.
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.
Or:
[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):
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)
This issue has been fixed in the following FlexNet Manager Suite releases: 2021 R1.4 / Mar 2022 (Cloud), 2022 R1 (On Premises)
Affected components: Agent, Inventory
Master issue ID: IOJ-2241253
Also known as: FNML-75025
Jan 19, 2022 01:27 AM - edited Jun 12, 2022 03:49 AM
Setting the JavaFullVersion=false fixed the issue for me! Thank you
Hi,
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
[ManageSoft\Tracker\CurrentVersion]
JavaFullVersion=False
EOF
/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 ?
Thanks
@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.
DECLARE @TargetName NVARCHAR(100)
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
DECLARE @btid INT
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?
Thanks
@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.
Hello, I was not able to find the JavaFullVersion or PerformJavaScan agent preferences in the official "Gathering FlexNet Inventory" documentation. Can I please ask you for documentation to these preferences? Thank you.