chrisa asked a question.
I am facing this issue where lmstat does not correctly report on the number of licenses in use by a significant margin. This typically happens when the license server is under some amount of traffic.
I am able to tell that lmstat is wrong because the license accounting does not add up from from lmstat and also I am able to validate from the license server logs that lmstat didn't fully or correctly report on status of license checkouts at the time of the lmstat call.
1. Why is this happening?
2. Is this behavior expected of lmstat? Also, could this be due to making lmstat queries with an outdated/buggy version? What version of lmstat is recommended as reliable?
3. What can i do to get reliable responses from lmstat?
PS: I am no license expert. Humbly seeking expert opinion
Hi @chrisa ,
As lmstat collects the data from the server to report it back, and in this setup, as the server is under high load, this can be expected.
What is the version of the server hosting the license and lmstat? If the lmstat older version, please use the utility of the same version as the server and check if you observe the same issue.
Thank you for confirming that this lmstat behavior can be expected under high load.
I actually tried different versions of lmstat and all had the same issue. The latest version I tried was v11.19.6.0. The server has a Flexnet version 11.19.6. Could the behavior be caused by a minor version mismatch between our lmutil(v11.19.6.0) and the FlexNet server (v11.19.6)?
Alternatively, we've noticed this often happens after an lmreread is triggered to add new licenses. Is there a likelihood that an lmreread operation could interfere with lmstat's ability to report license usage accurately?
To clarify, the lmreread operation always occurs during periods of high server load. This is because we add new licenses (which triggers lmreread) as a direct response to reduce license requests queuing. This makes it difficult to isolate whether the root cause is the high load itself or the lmreread operation after more investigation
Lmreread is also a load operation on the server, and since the server is already underload, this can be expected. I would request you to give server a break after running reread and then try to run lmstat to check for the output.
Gentle follow up to understand if there is a link between lmstat reporting and lmreread