Summary

Why is remaining linger time in lmstat showing wrong whenever license server restarted?

Question

We noticed the borrow timestamp (linger countdown value) will reset on the server side when the license server restarts. The count restarts, but the license returns at the right time (so it appears to be a problem with lmstat/lmtools reporting of the linger time).

Here are the simple reproduction steps (tested FNP 11.15.1 on Windows 64bit).

1. Launch the license server 
2. Launch the toolkit client lmborrow to setup the borrow period 
3. Launch the toolkit lmflex to borrow the license 
4. Check the LMTools?Perform Status enquiry or lmstat 
5. Stop the network license server OR restart the OS then start the server 
6. Check the Perform Status enquiry or lmstat again
7. Linger count starts over with each restart, but server log checks license in at appropriate time, regardless of linger count.

Is this expected behavior?

Answer

This issue was introduced with FNP 11.13.1, where linger time began showing with lmstat, per those release notes. Here is the relevant blurb:

...
lmstat and linger time

lmstat now displays the remaining linger time for each borrowed license.

Syntax: linger (<remaining linger time >/<total linger time >)

Example: lmstat.exe ?a ?c counted.lic

Output:
lmstat - Copyright (c) 1989-2014 Flexera Software LLC. All Rights Reserved.
Flexible License Manager status on Tue 4/14/2015 18:36
License server status: 27000@blrfnpdev01
License file(s) on blrfnpdev01: /data/home2/ishan/i_linux_main/FNP/_output/_debug/
11.13.1.0/main/i86_lsb/counted.lic:
blrfnpdev01: license server UP (MASTER) v11.13.1
Vendor daemon status (on blrfnpdev01):
demo: UP v11.13.1
Feature usage info:
Users of f1: (Total of 4 licenses issued; Total of 1 license in use)
"f1" v1.0, vendor: demo, expiry: 1-jan-0
floating license
ishan blrfnpdev01 /dev/pts/25 (v1.0) (blrfnpdev01/27000 202), start Tue 4/14 18:36
(linger: 468 / 480)

Where total linger time is 480 seconds and remaining time is 468 seconds. (FNP-1951)

What wasn't mentioned in that documentation (but is mentioned in the related issue FNP-1951) is that there is a limitation: linger time is not preserved across vendor daemon restart and vendor daemon running on machines with different time zones. Per comments on related issue FNP-10681, in general, data that is held 'volatile' (held in vendor daemon memory) will not survive across a vendor daemon restart. The request to modify this behavior was declined as will not fix.