We got confirmation from the client that the server is on a VM with open access to their internal network, not running over the internet.
In the config file that we can downloaded from your site, the block of code configuring the SCGI is commented out. We did not modify it when we share it with the client. Is that correct? Do we have to make any change similar to the one mentioned in your previous message?
TF server logs "double free or corruption" and aborts executionAnswered
Hello,
Our client is having issues with their floating server: the server stops working by itself after a while. The last messages in the terminal are the following:2024-09-18, 11:34:36 <warning>: The sent data exceeds the maximum allowed data. Request has been rejected. (Data came from a computer at ::ffff:10.5.8.15)double free or corruption (out)[1]+ Aborted sudo ./turbofloatserver -x
After restarting the process, everything goes back to work. However, this is happening one to two times every day which is not very sustainable. To give some more information, this server is running on a CentOS 8 VM configured in VMWare. We know that running the floating server on VMs is not secure, but this was a hard constraint set by the client which we could not avoid.
Does the “double free or corruption (out)” message tell something? Can you help us to understand what could be wrong here? Is there anything that our client should check on their end?
Thanks so much!
Answer
Is it being run over the internet? If so, they should disable “raw” support (just_scgi="true") and only use TFS over HTTPS.
Hello. Our client is still suffering from this. The server stops the execution at some point. They have had to re-launch it again many times which is not very sustainable.
We can confirm that their config file is modified only in the port number and the logger level to “notification”. Everything else is exactly how it is in the downloadable file from your website.
Can you help us to understand what could be causing this issue and how to fix it?
Hello, sorry for jumping on this thread. At Inbibo we reached out to other companies using LimeLM.
Apparently they have the same issue when the License Server is hosted on a Virtual Machine.
They can see the server quitting at random intervalls, exactly as we do.
We understand that running the License Server on a VM could facilitate piracy, but in our case it is more important to facilitate the adoption of our product by our top clients (which seem to prefer VMs).
We really need this to be fixed and working properly ASAP or at least help from you on which steps our clients should follow to resolve the issue on their end.
Answer
If you can reproduce the crash with the latest version, then please provide the steps to reproduce it.
Also: disable “raw” connections and force TFS over HTTPS. Again, directly addressed and linked to above.
Saying something doesn't work isn't useful in itself. Details are needed so we can reproduce it and fix it if it's a bug in our latest version (i.e. not something we've already addressed and released fixes for).
Hello, thanks for the reply.
Our client ended up installing a service in the VM running the server so that it automatically restarts the process if it gets aborted for any reason. After some weeks having this solution in place, no errors related to connection issues to the server were reported. For completeness, it was not necessary to make any change to the config file.
Thanks again for the help!