on Linux OS - FlexNet inventory agent not reporting after patch/reboot

[cartejam]

Hello,

We run a patch cycle every month, i have noticed that some but not all of the linux servers do not inventory successfully after patch/reboot, and the only way to get them to inventory again seems to be manually log on to server and run then command below, surely this should not be necessary?? has anyone else had this issue??

/opt/managesoft/bin/mgspolicy -t machine

/opt/managesoft/bin/ndtrack -t machine

[kclausen]

@cartejam - So that the Community has more information on your issue, can you identify:

What flavor of Linux is this (Red Hat, Ubuntu, CentOS, Debian, ???).

Is this happening for specific OS versions, or does it seem to be random?

[cartejam]

Hi Kirk,

Red Hat Enterprise Linux 8.3

Red Hat Enterprise Linux ES 6.10

Red Hat Enterprise Linux ES 7.4

Red Hat Enterprise Linux ES 7.6

Red Hat Enterprise Linux ES 7.8

Red Hat Enterprise Linux ES 7.9

SUSE Linux Enterprise Server 11 SP4 11.4

SUSE Linux Enterprise Server 12 SP3 12.3

[adrian_ritz1]

Hello @cartejam ,

Did you check if Flexera services are running?

For linux you can try the following:

/etc/init.d/ndtask start

https://docs.flexera.com/FlexNetManagerSuite2021R1/EN/GatherFNInv/index.html#SysRef/FlexNetInventoryAgent/topics/FA3-ServicesOnUnix.html

[cartejam]

Hi Adrian,

Service is running, but i think the NDTASK does not run the policy refresh perhaps

• ndtask — The agent's task launcher. This runs ndschedag which executes further command lines (for example, for ndtrack, ndupload, ndlaunch) to perform the required actions.

it is this that seems to not be run after the reboot imho. as when i call the command after the reboot/patching has completed

/opt/managesoft/bin/mgspolicy -t machine

everything goes back to normal, daily inventory commences

[ChrisG]

The symptoms you're seeing here of some computers not returning inventory after applying patches & rebooting doesn't immediately ring any bells for me as something that would be commonly occurring. The place I would start looking to understand what operations the agent is doing on both computers that are not working and computers that are working is the agent log files. These can be found in the /var/opt/managesoft/log/ directory.

[cartejam]

Hi Chris, I have a set of logs from a server which has been patched during Sept, please can you let me know who will want the logs, to investigate? should i raise a support ticket/case

Thank you

[ChrisG · Accepted solution]

You can look in the logs yourself to get a sense of what is going on. Comparing what you see in logs from a computer with problems to logs from a computer without problems may give some hints. You could also post log information here to see if other community members have any input or insight from the logs. (Scan through what you post first to ensure you're not posting any data which you consider sensitive.)

Logging a case with whoever provides your support for FlexNet Manager Suite is of course also a good option if you need some dedicated assistance.

[cartejam]

Hi Chris,

Looking at the logs, the Installation log we see on the 15 Sept, all looks great

15th Sept before patching occurred

then on the 16th following patching, the log file has this error and it repeats until todays date

log errors from the 16th Sept after patching

[ChrisG]

Good spotting! This logging suggests that agent configuration settings that are stored in the /var/opt/managesoft/etc/config.ini file have been lost - specifically, setting related to beacons that the agent can communicate with.

Can you compare what you see in that file on a working server to what you see on a non-working server?

Can you think of anything that is done during the patching process on these servers that may result in a change to this file, or that may trigger some RPM operation related to the FlexNet agent RPM package?

FWIW - I have heard anecdotes of settings being lost from this config.ini file intermittently and without any apparent reason. The association in this thread that it may be related to server patching operations is an intriguing possibility... (CC @nagaeendra - I think you may have seen something like this.)

[nagaeendra]

Hi @ChrisG ,

Yes, end result of the agent seem to be same, from our side I don't have evidence with this scenario, never the less will have this verified. 

Also as mentioned we are working on auto-healing such agent with 3rd party tool. and Thanks Chris for looping in, any such info will be good and useful in fixing the issue better. 

Hi @cartejam,  out of curiosity did you happen to notice what kind of patch causing this issue with the agents

[cartejam]

Hi, so i have done a little bit more digging

I have got two config.ini from linux server and here is the screen shot of them together, side by side

the left side is from a good inventory server, the right side ini file from a server which has not inventoried since it was patched

The config.ini from the server which is working has far more sections which are complete

the config.ini file on the server which does not inventory, have missing sections, yet it did work!

My team are still looking at what patches applied to the server, but i wonder why would this file lose settings??

[cartejam]

Hello,

So the corruption is see on the file

/var/opt/managesoft/etc/config.ini

Is there a way to reset this file so that the device will inventory?

[durgeshsingh]

Try to run /opt/managesoft/bin mgspolicy -t machine to re enforce connection. 

[cartejam]

Hi,

So i tried this already, it did not resolve the server inventory or config.ini.

I am trying this fix next

https://community.flexera.com/t5/FlexNet-Manager-Forum/FNMS-Inventory-Agent-config-corrupt/m-p/201600#M12399

I will let you know if it works!

What i really would like to know if why this file got corrupted and how to prevent this from re-occuring in future, i have a number of linux servers to heal and i am losing the inventory for over 100+ servers which for no reason got corrupt

[ChrisG]

Two possible approaches to restoring the configuration of an agent on a UNIX-like operating system that has got corrupted are as follows.

Uninstall & reinstall

1. Uninstall the agent
2. Remove the /var/opt/managesoft directory
3. Re-install the agent

Re-initialize configuration and re-bootstrap the agent by applying policy

This can be done by executing commands like the following (as a user with root rights):

/opt/managesoft/bin/mgsconfig -i /opt/managesoft/install/default.ini

/opt/managesoft/bin/mgspolicy -t Machine -o DownloadRootURL=http://your-beacon/ManageSoftDL