In terms of what information is used to uniquely identify the software, I assume you mean something like the SI key?

For IBM Tivoli Monitoring, looking at the IBM.TivoliMonitoring pattern module, the SI key appears to be generated from the SI type and Host key.  The version information is not used in the construction of the key.

As a principle, I'd expect ADDM to retain an SI version value it had previously discovered, it was unable to obtain it on a subsequent scan (for whatever reason).  Is that a fair assessment & is that how ADDM should work in regard to software discovery?

I can only really comment on IBM Tivoli Monitoring products at this point.  I know that there are multiple agents available, but would only expect to see a particular agent running once on a given host.

Interestingly, for one of the hosts running some ITM products (IBM Tivoli Monitoring Linux OS Monitoring Agent & IBM Tivoli Monitoring Log File Agent), we lost the version info again for both during the last scan.  There are 2 session logs for this last host scan and I can see that the 'cinfo' command ran and produced the required output in the earliest session log.  However, the discovery access doesn't show this in the command result and instead shows the 'Connection timed out' error.  I don't understand why that would be.

I have raised case # 00398568 to investigate.

The tail of the 1st session log looks like this, just after the cinfo command is run.

I'd expect to see the 'Permission denied' output in the discovery command result, as it indicates that we can't get results from the command when run unelevated.  We then attempt to run the same command with elevated privs which we get the required command output.

Unfortunately, we no longer have the ability to log on to target hosts with our discovery ID to test things like this.  I'll see if I can find somebody who can do this.

Forgive my ignorance, but how can you tell that there are lots of failures from the command?  Are you referring to the number of "Permission denied" messages?

When we successfully obtain version info, it usually looks like this (the following is lifted from another example host, where unelevated cinfo didn't produce the required result but running it elevated did).  We found that we didn't need to run the command elevated on all hosts, just some.  Now I'm thinking that maybe we should maybe run it elevated every time?

Sorry, I was editing my last comment when you replied & wanted to ensure you saw my last update?

I'm wondering if we should just run the command elevated every time?  If so, we could obviously alter our existing custom pattern accordingly, just to do this.  However, I'm not sure if this is something that would be changed in a TKU pattern, based on how PRIV_RUNCMD is used these days?

I'll see what I can to in terms of logging on to the host and redirecting stderr.

The bit I don't understand,is the intermittent nature of how the output from un-elevated cinfo command is being handled.  I wouldn't expect the "Permission denied" output to change from day-to-day, so what's preventing it appearing as per the session log in the discovery cmd result on some days?

In regard to custom patterns, we try to avoid these as much as possible to stay aligned to TKU versions.  For this scenario, we originally coded an 'overlay' pattern which co-existed with the TKU pattern and filled in the blanks (i.e. triggering on the respective SI types, checking for blank versions and running an elevated cinfo command).  We then observed some timing issues, as a results of their being a undetermined about of time between the respective patterns being triggered & commands being run.  As a result, we collapsed this logic in to a single custom pattern, de-activating the TKU ITM Common Functions pattern in the process.  This meant that if the unelevated cinfo command returned "Permission denied", we'd immediately try again with elevated privs - I've attached the custom pattern to the case.

For info, the following screenshots are from the latest session logs.  These relate to the last scan of the same host, which did successfully get the version info - obtained because the elevated cinfo command was executed.

Taken from the 1st of 3 session logs for this scan:

Taken from the 3rd of 3 session logs for this scan: