License Manager and Inactivity Timeout (not always working)

[Anonymous]

I have an issue with (some) inactive licenses not being returned after the 'timeoutall' option set.

So to start, I have in my adskflex.opt file, the following line:

MAX_BORROW_HOURS 85797BDSS_F 240
MAX_BORROW_HOURS 85787BDSPRM_F 240
MAX_BORROW_HOURS 85788BDSADV_F 240
TIMEOUTALL 900

When starting my license server, I get in my log:

...
10:13:22 (adskflex) EXTERNAL FILTERS are OFF
10:13:22 (adskflex) Max borrow interval for feature, 85797BDSS_F, set to 240 hours
10:13:22 (adskflex) Max borrow interval for feature, 85787BDSPRM_F, set to 240 hours
10:13:22 (adskflex) Max borrow interval for feature, 85788BDSADV_F, set to 240 hours
10:13:22 (adskflex) ALL FEATURES: INACTIVITY TIMEOUT set to 900 seconds
10:13:22 (lmgrd) adskflex using TCP-port 2080
10:13:22 (adskflex) SLOG: Statistics Log Frequency is 240 minute(s).
10:13:22 (adskflex) SLOG: TS update poll interval is 600 seconds.
10:13:22 (adskflex) SLOG: Activation borrow reclaim percentage is 0.
...

So as far as I can tell, it recognizes that the inactivity timeout is set...
The inactivity timeout works (at least some time) because I tested and my license was returned appropriately.

However...I have a few instances where the license does not return. And I am finding it extremely frustrating.  As it is not working as advertised.  😞  We don't have a surplus of licenses and have been running against the license wall.  I have investigated some of the instances, and they are running AutoCAD Architecture (specifically), and in 1 instance MEP and I have seen it with both 2014 and 2016.  They leave at 5PM, so I entirely expect (if nothing else) that the license be returned overnight.   It is not.  But again, for some it appears to return licenses properly.

I have spoken with them, and they are not running any extended process (rendering or anything that should take hours) and they are running the out-of-box ACAD Arch.

I would LOVE to get their licenses to return properly.
Okay AutoDesk, WHAT are the reasons that a license would NOT be returned?  Bueller?  Bueller? Anyone?

Are there any logs I can look at to help identify the blockage?

running:

10:13:21 (lmgrd) (@lmgrd-SLOG@) ===============================================
10:13:21 (lmgrd) (@lmgrd-SLOG@) === LMGRD ===
10:13:21 (lmgrd) (@lmgrd-SLOG@) Start-Date: Thu Jun 02 2016 10:13:21 Eastern Daylight Time
10:13:21 (lmgrd) (@lmgrd-SLOG@) PID: 5008
10:13:21 (lmgrd) (@lmgrd-SLOG@) LMGRD Version: v11.13.1.2 build 173302 x64_n6 ( build 173302 (ipv6))
10:13:21 (lmgrd) (@lmgrd-SLOG@) 
10:13:21 (lmgrd) (@lmgrd-SLOG@) === Network Info ===
10:13:21 (lmgrd) (@lmgrd-SLOG@) Listening port: 27000
10:13:21 (lmgrd) (@lmgrd-SLOG@) 
10:13:21 (lmgrd) (@lmgrd-SLOG@) === Startup Info ===
10:13:21 (lmgrd) (@lmgrd-SLOG@) Is LS run as a service: Yes
10:13:21 (lmgrd) (@lmgrd-SLOG@) Server Configuration: Single Server
10:13:21 (lmgrd) (@lmgrd-SLOG@) Command-line options used at LS startup: -c C:\Program Files\Autodesk Network License Manager\License\FM-Autodesk-LM_ADSK_2016.lic -l C:\Program Files\Autodesk Network License Manager\Log\Debug.log -z -s 
10:13:21 (lmgrd) (@lmgrd-SLOG@) License file(s) used:  C:\Program Files\Autodesk Network License Manager\License\FM-Autodesk-LM_ADSK_2016.lic
10:13:21 (lmgrd) (@lmgrd-SLOG@) ===============================================

Preemptive Thanks,

Erik

[TravisNave]

So if you see (INACTIVE) then the TIMEOUTALL option is obviously working.
However, it does only work when the application is considered idle. I have
also seen instances where users have seemingly defeated this. Either they
have found a way for their computer to never be idle, or they have borrowed
a license, or (in some instances) I have found that leaving the application
in the middle of a command waiting for input will prevent the application
from officially being idle.

You might check to see if the licenses that are hanging on are doing so
with the same users over and over again.

[Mark.Lancaster]

@rkmcswain

Do you have an option file?  Is the option file set to all timeout or certain products?

When the license file was created, did all assets get created at the same time or within a 24 hr period?

[rkmcswain]

@TravisNave, I have only been able to intimately check out one particular case. But in this one case, the user left her C3D open when she left on Thursday. She did not come into the office on Friday, Saturday, or Sunday. I caught up with her first thing Monday morning when she arrived. By this time, my reporting showed she has a license for ±90 hours straight. I examined her C3D, and there was no command active, no dialog, nothing else funky running on the PC, and she had not remoted into this PC during any of this time. Based on my conversation with this employee and my observations, the PC had been idle from Thursday afternoon until Monday when she arrived.

Normally this is not an issue. Our CAD users are generally consuming licenses from 6am to 6pm. So having a couple of dozen PCs licenses being used at night or over a weekend is not going to impact the ability for users to obtain a license. But in this case, the license was being consumed on that Friday, but NOT being used (she was out of the office). So the impact is really when a license that could be free'ed up, doesn't get returned during high usage periods (in our case, 6am-6pm)

Of course this is also leading to bad data in my reports, because now I know some percentage of users are not actually using the software although it shows a license is in use. 

I am aware of "borrowed" licenses and none of these are "borrowed".

Finally, yes it is the same users who are repeatably having this problem. I can't easily ID anything common about them either. A mix of O/S (Win7, Win10), a slight mix of hardware, a mix of geographic locations, etc. That is not to say there is not a common factor, I just have not identified it yet.

Thanks.

[rkmcswain]

@Mark.Lancaster wrote:

Do you have an option file? Of course. It won't perform the timeout function without one, and the proper timeout syntax in the file, correct?

Is the option file set to all timeout or certain products?

All

When the license file was created, did all assets get created at the same time or within a 24 hr period?

Sorry, I don't understand what you mean by assets. We have multiple LMs running. The OPTIONS file was updated and the license file re-read on all LMs within a ±20 minute period. This was back in ±November. During the Christmas break, all servers were taken off line for normal Windows maintenance, so on January 02, when all employees arrived back, there were no extended license check-outs. Everyone started at Zero that day. This should rule out any lingering issues that might have existed in the LM before we applied the edited OPTIONs file.

[TravisNave]

I would say that if your debug log shows that some licenses of C3D have
been returned due to INACTIVE, then it is reasonable to assume that the
options file is working. There simply must be a reason from the
client-side that is preventing the "idle" nature of the software. Of
course, Autodesk never has officially stated exactly what constitutes an
idle license.

[Mark.Lancaster]

@rkmcswain

Sorry for the confusion.  The word asset in this case was meant as:  Were all of the products in the license file all generated within a 24 hr period.  When products within your license are done at different times I've seen odd issues.   Especially when products are related but appear in different suites/collection and their license portion was generated on different days.

However it appears from your reply the option file was only updated, is the correct?

[rkmcswain]

@Mark.Lancaster wrote:

The word asset in this case was meant as: Were all of the products in the license file all generated within a 24 hr period.

To the best of my knowledge, all of our .LIC files were generated at roughly the same time by our reseller. Thanks!

[rkmcswain]

@TravisNave 

Anyone ever figure out any more about this? It's Saturday morning, nobody is working, and I've got 17 CAD licenses checked out (not borrowed). Some of them have had a license for 20 hours, some for as many as 90 hours. I know there are more PCs that have the issue because on most nights, the number is around 35. (I guess some people actually shut down CAD for the weekend...)

Just out of curiosity, anyone know what these sections in the debug.log file are actually describing? The "Last 10 client requests" section is interesting because these are the same clients who are not honoring the timeout. 

Our 2017 AutoCAD based products do have the AutoCAD 2017.1.2 update applied per this bulletin. No difference. 

[rkmcswain]

@TravisNave  wrote:

LMREMOVE is not a supported option for Autodesk licenses.

Someone should inform the KB article authors.

[TravisNave]

That's interesting. But you do actually show some (INACTIVE) entries in
your debug.log file, correct? Rather, it's only a select few who seem to
circumvent the idle process every time?

[TravisNave]

I got into some pretty hot water circa 2005 about this issue with
Autodesk. LMREMOVE is not supported, apparently. I'm surprised that
article exists. Either the author is ignorant of license circumventing,
and/or is unaware that the keep-alive functionality of Autodesk software
would immediately recheck out a license after forced removal.

In any case, though I haven't officially made my 2020 KB article on the NLM
yet, for your particular issue, you might try the latest version of the
NLM, which will be released with the 2020 product line in a few weeks.


https://knowledge.autodesk.com/sites/default/files/file_downloads/nlm11.16.2.0_ipv4_ipv6_win64.msi

You can try that or perhaps even downgrade to 11.7 and see if your
TIMEOUTALL option works better. If the problem is a daemon one, it might.
If it is a problem with the client, it likely won't.

[rkmcswain]

@TravisNave  wrote:
That's interesting. But you do actually show some (INACTIVE) entries in
your debug.log file, correct? Rather, it's only a select few who seem to
circumvent the idle process every time?

---

Yes, plenty of INACTIVE license returns.

Of course, we could have PCs where the TIMEOUT is not working, but we don't know it because the user shuts down every time. Not really a problem, unless they forget to shut down and leave for 1/2 day.

As I said in a post above, there doesn't seem to be any one common factor. Various O/S, various hardware, various geographical locations. Although all clients do have the same env var for ADSKFLEX_LICENSE_FILE and FLEXLM_TIMEOUT (not that I think those matter, but you never know.)

If we just knew what to look for (the actual process that pings the server, the heartbeat...), perhaps we could determine why in some cases this process doesn't stop when the PC is otherwise idle.

[rkmcswain]

@TravisNave - I was able to RDP into a PC right now which is otherwise idle, but has had a license for 50+ hours.

I ran Process Monitor and I can see that acad.exe, running under the other users account, is sending 36 bytes and receiving back 168 bytes of data to/from the LM, every 60 seconds. This seems to be the "heartbeat". 

So then I remoted into the LM and ran Process Monitor on it, and I can see every client in the list of misbehaving clients, sitting there pinging the LM every 60 seconds, with a reply from the LM. 

I have fired up ACAD on a PC where I know the TIMEOUT does work. I'll let it be idle for the TIMEOUT period, then check the LM to see if the chatter is still happening. 

[rkmcswain]

On the PC where I know the TIMEOUT is working, I opened ACAD, it obtained a license at 11:13:08 and then I left it idle. The license was returned due to INACTIVITY at 12:08:05, and when I view the network activity on the LM, there is no communication with this client PC.

So all that really proves is that when a license is returned due to INACTIVITY, that the communication with the LM ceases. Well, actually it happens the other way around according to the documentation from Macrovision. An idle client doesn't send heartbeats to the LM. When the LM detects [TIMEOUTVALUE] minutes of no heartbeat, it revokes the license.

[TravisNave]

Where we at on this, brother?

[rkmcswain]

I wish I knew @TravisNave .....

Last night between midnight and 4am, 30+ licenses were "in use", some of them have had a license in excess of 80 hours straight. If the number was 3 or 4, I would say those users might have left a command active (which keeps the heartbeat going), but I know for a fact that is not the case on these 30+ PCs.

Obviously, I'm not worried about overnight usage, but if these machines are not releasing the license at night, that means they are not releasing it during the day either. Could we beat the users over the head and tell them to close CAD when their not using it? Sure. But we shouldn't have to - if the TIMEOUT feature worked as advertised.

Any other thoughts on your end?

[TravisNave]

Have you tried using the TIMEOUT and TIMEOUTALL options both? The only
other thing I could think of would be to write a batch script that stops
the NLM at a scheduled time in the middle of the night for long enough to
kill the active sessions. Then restart the service afterwards. By default
the NLM resets at midnight anyway, but it's not long enough to kill off
anything. A script put on the server and ran as a scheduled task might be
enough to solve your issue. The active user, in theory, shouldn't be aware
until they try to access the software and one are available. That would
provide them a save option. Otherwise, it would just continue on in the
morning and grab a license upon becoming active.

[rkmcswain]

To answer your first question, no. But since it works for ~80% of the clients, I figure it's on the client side. 

Yeah, workarounds... but it should work as advertised. If there were just more documentation on it, I'd be happy to do the legwork and trace it down. There must be something more to why a client keeps the heartbeat going despite no activity.

It could be something simple. For example, if you have a windows screen saver timeout set up, but you leave a video playing in WMP, the screen saver will never launch, because the playing video is considered activity. Perhaps there is something like this that makes AutoCAD think it's active.

@TravisNave 

[TravisNave]

The only instances I know of is when AutoCAD is left in the middle of a
command -- that sometimes prevents the program from going idle.

[rkmcswain]

Still seeing the same issues. Just keeping this thread alive with a heartbeat..... @TravisNave