me again with licensing issues. I’m on 10 licenses and have 10 nodes. The problems are with Power Management when the machines get restarted I’m always, every time, getting a License error that all of my 10 licenses are being used, but actually, only 9 machines are up and running, the tenth machine is triggering the license error and I have to manually restart the license server.
This happens EVERY TIME one of my machines gets stalled or restarted, the license just doesn’t get released fast enough and then the lic. server refuses to grant the license to the newly restarted machine - hence the errors.
Is there anything I can do about this? A lic. release time treshold or anything like that? I hate restarting the license server (meaning the flexlm) every time.
One thing to check for is if the slave application is shutting down gracefully. If it’s stalled, that means the slave crashed, and was probably unable to check it’s license back in. However, from our experience, even when the slave dies like this, the license usually gets checked back in.
Are you still on 5.0, or are you on 5.1 now? Just curious if you’re using the lmgrd binary that came with 5.0 or 5.1. The one for 5.1 is much newer, and maybe it’s possible that it handles these crashes better.
I was using an older version of 5.1 beta, but recently (about a week ago?) upgraded to the full 5.1 release, but I haven’t reinstalled the licensing server (I’m using it for The Foundry products as well, so I don’t want to mess with it too much). Should I reinstall the license server as well? Where do I get the license server version to check if it’s recent or not?
You can check the version number in LMTools by selecting Help -> About. You can also right-click on lmgrd.exe and select Properties. The Details tab should also list the version number. The version shipped with 5.1 is 11.10. The one shipped with 5.0 is 11.4.
I did some googling, and it turns out this is a well known issue with flexlm. The lmutils.exe binary we ship has an lmremove option that can apparently be used to free up a license without restarting the license server. Googling “lmremove” will turn up a bunch of hits, for example: support.esri.com/en/knowledgebas … tail/11809
This still isn’t ideal though because it requires manual work.
Not yet, no. I’m looking into ways of working around this in code.
Are you running your Slave instances as a service? Through my testing and mentions from other users with the similar problem, one of the few times Slaves don’t naturally check their licenses back in is when running as a service. This is due to the fact that the Slave is closing after the network has gone down.
We are working on a fix for an upcoming 5.2 maintenance release. We hope to have it uploaded to the Deadline beta board next week, but there isn’t a timeline for a public release yet. If you’re not already on the Deadline beta board, and you want access to the beta release, let me know and I’ll add you to the beta group.
The plan is to give the launcher service the TCPIP dependency. This means that the launcher (and therefore the slave) won’t start until after TCPIP is available. If TCPIP were to be shut down (ie: on machine shut down), then the launcher service will be shut down first.
Because we need the slave to check in its license while TCPIP is available, we will be modifying the launcher service so that it stops the slave before it shuts down itself. This means that the slave is essentially tied to the launcher service now (whereas before it could remain running if the launcher service was shut down). However, we think this is a necessity to ensure that the slave checks in its license properly.
Great stuff, thanks Ryan.
I’d definitely like access to that beta board. Cheers.
As a side, I was at the 3DS London event last Wednesday where Bobo and Mike Owen presented Deadline 5.2 and a sneak peek at 6 - really impressed by what you guys have done. Looks great.