RLM builds a list of license files, in the following order:

• <isvname>_LICENSE environment (if it exists) - this can be a list of license files, or [email protected] specifications
• RLM_LICENSE environment (if <isvname>_LICENSE doesn't exist) a list, similar to the above
• LF specified in argument 1 to rlm_init() - this is a single license file or [email protected] or directory. Typically software publishers set this to the current directory (".")
• license files in directory specified by argument 2 to rlm_init()

These are all put into a single list, in that order.

However, if the you set the environment variable RLM_PATH_RANDOMIZE, then the list is started from some random point, wrapping back around to the front of the original list.

When license checkouts are much slower on one (or a few) systems, the problem is usually something in the environment on that particular system. Most likely, there is a license file (or [email protected] in RLM_LICENSE) that specifies a server which is unreachable from that system, so the request to the (unreachable) server times out, then succeeds from the "good" server.

Another possibility, if your Software Provider has integrated an ISV-defined hostid, is that there may be something about the particular system causing the ISV-defined hostid code to take longer to run. Note that the ISV-defined hostid code will be called before the call to check out the license.

When RLM is looking for a match between the hostid in the license file and a hostid on the machine, it looks on the at all instances of the hostid type in the license file. If you have an ethernet hostid in the license file, RLM looks at the addresses of all ethernet devices in the system. If the device whose address is in the license file is no longer in the system configuration, RLM will not find a hostid match. Sometimes these devices come and go on laptops - we call these transient devices. For example, a wireless adapter might not always appear.

On Windows, RLM uses the device description (as you see in ipconfig /all) to sort the list of ethernet devices returned by "rlmhostid [ether]", such that transient devices such as wireless interfaces and VPN devices are at the end of the list. Thus choosing the first device in the list returned by rlmhostid yields the best chance of having a stable hostid.

RLM Activation Requests can time out for a number of reasons. Please see this blog post for help diagnosing these problems.

If you want to serve licenses across a firewall, both license servers, i.e. RLM and the ISV server, need known port numbers in order for your firewall to pass requests on these ports.
The RLM server is always at a known port number - specified in the license file on the SERVER or HOST line.
Typically, RLM starts up all the ISV servers with dynamic port numbers which are not known before startup time.

It is possible to have RLM assign fixed port numbers to the ISV servers. To do this, specify the port number for the ISV server on the ISV line. The port number is the fifth parameter in the isv line:

ISV isvname isv-binary options-file port-number



In order to specify the port number, you must also specify an options file for this ISV server.

Once you have specified the port number, instruct your firewall to allow connections to both the port number on the SERVER line (for RLM) and the port numbers on any ISV lines.

You must restart RLM in order for any port changes to take effect. Restarting the ISV server via the web interface or rlmreread does not restart RLM.

Note: Beginning in RLM v9.0, you can specify the ISV server port number with the optional "port=xxx" parameter on the ISV line, as such:

ISV isvname binary=isv-binary port=port-number
or
ISV isvname isv-binary port=port-number



Using this method, you do not have to specify an ISV options file.

That error message typically indicates another copy of RLM is running which is using port 5054 or 9000.

Check your system for other running copies of the RLM server and if they should not be running, stop them. Then, restart the RLM server.

Another possible problem is that another program is using the port. Use the "netstat" command to see if another program is using this port.

Finally, we have reports that some systems get this error, even when no program is using port 5054, if the machine's name and IP address are not present in the hosts file. Adding the hostname and IP address to the hosts file will resolve this problem.

Q: I have software from 2 different Software Companies, and when I attempt to run the license servers, they give "port in use" errors. What should I do?

A: You have the choice to run one rlm for many ISV servers, or one rlm for each ISV server that you have.

Unlike older license managers, each instance of rlm requires one client connection port (specified on the HOST or SERVER line in the license file), and one web server port. The rlm server can bind multiple client connection ports if it is started with multiple license files which have different port numbers on their HOST or SERVER lines.

The web server port defaults to 5054 (or 9000 in older releases), and can be changed on the rlm command line with "-ws ". Or the web server can be disabled altogether with "-nows", but we don't recommend disabling it.

If you want to run one rlm for multiple ISV servers:

This is the easiest way to configure rlm.

You'll need (at least) 1 client connection port and 1 web server port. Note that you can use one or multiple client connection ports. rlm listens for client connections on each unique port it finds on the HOST or SERVER line of the license files it reads. RLM does this so that you can add a new license file from a new ISV without having to change it, and the client software from the new ISV is then unaware that the rlm process is serving other ISVs licenses.

The easiest way to accomplish this is to put the license files and ISV servers in the same directory as rlm, and then just start rlm with its normal defaults.

If you want to run one rlm per ISV server for 2 ISVs:

You'll need 2 client connection ports and 2 web server ports. This means you will have to ensure that both license files specify different port numbers on the HOST (or SERVER) line, and you must be sure to start at least one copy of rlm with the "-ws port" option, specifying a different port # than the default.

In this case, you must keep the license files in separate directories, or at a minimum, keep them in a directory that is separate from any of the rlm binaries and reference them with a "-c license_file" specification for each copy of rlm.

The failover server checks the health of the "failed" server every 2 minutes. It can then take up to one additional minute before the failover server begins serving licenses.

This error nearly always means that another copy of the ISV server is running.

Check the running processes on the system and kill the other copy of the ISV server. Generally, there may be another copy of rlm (or rlm.exe) running as well. Of course, the other server may be operating and everything may be fine, so you may not need to kill it. If the ISV server is running without an rlm server running, you will need to kill the ISV server.

This can also happen if the lockfile directory is not writable by the user who started the server. Ensure that the lockfile directory is writable by the user who starts the server. The "rlm directory" is:

/var/tmp on unix/mac, or
ProgramData\Reprise (vista and later) or 
Docs and Settings\All Users\Application Data\Reprise (pre-vista).

The server's lock file name is rlmlock<isv> on windows, and .rlmlock<isv> on linux, where <isv> is the ISV name. If you have lockfile problems on linux which can't be attributed to another copy of the server running, then check the protection on /var/tmp to make sure it allows world rwx. On Windows, what sometimes happens when the first version of the RLM server to run on a system is pre-v9.4, is that the lock file is created with restrictive permissions that don't allow a different user to lock it. 9.4 and later create the Reprise folder with wide-open access that is inherited by files created in it, so this problem doesn't occur. Deleting the lock file is OK to solve the immediate problem.

This message nearly always means that there is another copy of RLM running on this port. Check the system and kill the running rlm process.

In certain cases, Symantec anti-virus software blocks some rlm messages. The symptoms vary, but usually the application receives network read errors (-104), or licenses are simply not checked back in.

In order to solve this problem, run your ISV server on a known port # (use port=xxx on the ISV line), and tell the Symantec software to exclude that port.

WAN access to the license server should be no problem. We don't have any feedback from RLM customers who have tried this, but back in the FLEXlm days a number of end users did this with no problem - and RLM and FLEX use the network in similar ways. The checkout message is less than 100 bytes, but before checkout there's an initial connection message that's on the order of 1KB. Still pretty small in the scheme of things, and that only needs to happen once per client connection to the server.

Here are a couple of configuration/policy items that bear on WAN use of RLM:

- RLM_CONNECT_TIMEOUT is an environment variable that the end user can set (or you can set it programatically in your code). By default, an RLM client uses a 10-second timeout when making a connection to a license server. In a WAN with a lot of latency, this can be used to up the connect timeout and prevent connection failures.

- The application's heartbeat usage could be an issue on extremely slow and/or flakey networks. If the heartbeat interval is less than the maximum round-trip latency (of tiny messages) on your network AND if the application's tolerance of missed heartbeats is 0, you could have a situation where your app decides that the license server has gone away when it's really just a slow network. That would be an extreme situation though, as the minimum heartbeat interval that RLM allows is 30 seconds.

The RLM License Administrator Bundle contains a performance test suite that you can run on your WAN. The reports are in terms of how long it takes to get a given unit of work done (say, 300 checkouts). Running that will give you an idea of how well RLM will perform in a specific environment.

The RLM server log file frequently contains information that identifies the startup problem.

The RLM log file file location is specified by the "-dlog logfile" argument on the RLM command line when using the "-install_service" option. If you install the RLM service via the RLM web interface, the log file location is specified in the box labeled "Server Debug Log".

In RLM v8 and later if you specify a relative path, that path will be relative to the location of rlm.exe. For example, if the debug log path is specified as "myrlmlog.log" and rlm.exe is located in "c:\rlm", the debug log will be "c:\rlm\myrlmlog.log".

In versions prior to v8, the specified relative path is relative to \windows\system32.

When running as a Windows service, rlm.exe and the ISV server run under the user name "SYSTEM". Make sure that the log file location that you specify can be written to by that user.

Launch a command window using "Run as administrator", and install RLM from the new command window. "Run as administrator" is an option when you right-click on the command window icon on the desktop or in the start menu.

Reprise has had reports on a very limited number of systems that RLM fails to start the ISV server, with errors similar to the following written to the debug log (note: the ISV name will be your ISV name, not necessarily "demo"):

03/16 04:12 (demo) select() failure: Unknown error
03/16 04:12 (demo) Out of file descriptors: Cannot clone communications handle: Unknown error
<last error repeats 10 times>
03/16 04:12 (demo) Too many errors on main socket, exiting



This error sometimes results in debug log output similar to the following:

01/06 10:11 (rlm) Starting ISV demo
01/06 10:11 (rlm) Error in getsockname() call 13
01/06 10:11 (rlm) ... demo on port 57809
01/06 10:11 (rlm) New thread created to watch ISV demo
01/06 10:11 (rlm) demo initialization error: 1, not restarting



Or the following:

01/05 12:50 (rlm) Starting ISV servers:
01/05 12:50 (rlm) ... demo on port 1088
01/05 12:50 (rlm) New thread created to watch ISV demo
01/05 12:50 (rlm) demo - communication (socket) problems



This problem is caused by a registry corruption (not induced by RLM) that affects some network operations. The fix is to open a command window and type the command:

$ netsh winsock reset



Should the above "netsh" command not solve the problem, Microsoft has published the following article on how to correct the registry when this occurs. Note that the error message indicating the problem is different in the article than the RLM error message indicating the problem, but the underlying cause is the same.

http://support.microsoft.com/default.aspx?scid=kb;en-us;817571

Q: When I try to use rlm to install rlm.exe as a service on Windows 7 I get a message that says "Access to Service Control Manager denied" even though I'm running in an account with Administrator rights. What should I do?

A: In some cases on Windows 7 a program doesn't get the rights of the invoking user. But if you launch rlm.exe by right-clicking on its icon and selecting "Run as administrator", then rlm will run with the sufficient rights, and it can install itself as a service.

Sometimes RLM on Windows uses a MAC address as hostid which is later not present in the system, leading to a wrong hostid error when the application tries to check out a license, or when starting up a license server. What should we do about this?

A: The rlmhostid utility, and the internal routines which determine hostids, return all the MAC addresses found in the system. Some of those may be for devices that are not always present in the system, for example Virtual Private Networks, wireless adapters, wireless phones plugged in to USB ports, etc. If a license is created which is locked to one of these transient hostids, the license will be valid if the transient device is present. Thus it is a good idea to lock licenses to non-transient device addresses.

In RLM v8 and later, the list of MAC addresses returned by rlmhostid, and returned by internal routines, is ordered such that the addresses of potentially transient devices are at the end of the list. Thus it is a good idea when choosing from a list of MAC addresses to choose from the beginning of the list if using RLM v8 or above. If using a version prior to v8, you can use "ipconfig /all" to see the list of MAC addresses along with a description of each one. You can use the description to choose one that isn't transient.

Note that when RLM is matching the hostid from a license with the hostids present on the machine at runtime, it only requires one of the hostids to match the one in the license.

Q: Certain RLM operations fail on Windows 2000 when attempted by a restricted user account. These operations include checking out a "single" license and starting up the rlm server. How do I fix this?

A: RLM uses the common application data folder to store operational files. On Windows 2000, restricted users cannot write to this folder by default. The workaround is to grant write access to the common application folder to restricted accounts. The folder is typically "\Documents and Setings\All Users\Application Data". In a non-restricted user account, right-click on this folder and select Properties, then select the Security tab. In the "name" portion of the tab, click on "Everyone". In the "permissions" portion of the tab on the bottom, click the "Full Control" checkbox. Then click the OK button.

Repeat the instructions above for the "Reprise" folder (if it exists). The Reprise folder is inside the Application Data folder, e.g.:

"\Documents and Setings\All Users\Application Data\Reprise".

We have had reports of 32-bit RLM servers failing to execute on a 64-bit Ubuntu system.

The symptom, when attempting to run the RLM servers, is an error similar to:

bash: ./rlm: No such file or directory

This is due to the system not having the 32-bit system libraries. To correct this problem, execute the following on the target system:

sudo apt-get install ia32-libs (for older systems)

or on newer systems:

dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libstdc++6:i386