This error is returned when the http request receives an internal server error from the HTTP server (status 500).

This means that something is misconfigured on your web server, and the only way to find out what it is is to look at the web server error log.

In this case, the first thing you should do is to look at the web server error log and attempt to resolve the configuration problem that way. We cannot help you without this information, and it is likely that you will be able to solve the problem when you see the error log.

This error (-134, RLM_EH_ACT_BADSTAT, Bad return data from webserver) most likely means that there is a problem with the license generator, ISV_mklic.

Try running the license generator by hand on the webserver machine. When you run it from the command line, you should see something like the following:

% demo_mklic

Content-type: text/html

If you get no output, or the program fails in some way, it’s likely that you have a binary for the wrong architecture or a permission problem, etc.

Q: When attempting to activate a license (using either rlm_act_request() or the rlm web interface), the license is not generated and an error of “Bad HTTP transaction with activation server” RLM_EH_BADHTTP (-136) is generated. What is the problem?

A: The HTTP error will be listed along with the error message. This may help you to find the problem.

This problem generally occurs when there is some problem with the installation.

This can happen for a number of reasons:

• you have specified an ISV name which is incorrect
• the ISV web server is not configured correctly
• the ISV_mklic binary is not for the correct architecture

One way to test whether you have a correct binary is to attempt to run it by hand. If your webserver is running on a unix system, try the following:

ISV_mklic << EOF

akey=1&hostid=2&

EOF

This should result in output indicating that the activation key was not found (unless you have an activation key of “1”). If the program fails to run, you either have a bad binary or a permission problem.

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 port@host specifications
• RLM_LICENSE environment (if _LICENSE doesn’t exist) a list, similar to the above
• A license file specified in argument 1 to rlm_init() – this is a single license file or port@host 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 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 port@host 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.

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”.

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

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. 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.

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.

Checking the health of the connection is done to make sure that the server has not been shut down or exited for any reason. The license count is maintained in the server in memory. If the server is restarted, then it starts over with a fresh count of licenses available. So, for example, if you have 10 licenses checked out, then the server is shut down and restarted, those 10 licenses become available again. Checking with the server in your application prevents your application from continuing to run while it thinks it has a license and the server giving that license out again to a new client.

If you check every couple of minutes, that should be sufficient. On the other hand, if your product only runs for a couple of minutes, you can skip this check completely.

If you call rlm_init_disconn(), you must check with the server at least as often as the promise parameter you specified.

If you installed the RLM kit on 2 different platforms and ran the default INSTALL procedure, you may have created different publc/private key pairs. Decide which key pair you want to use, and copy them to all the platforms you are using, and re-compile:

• rlmsign
• your  isv server
• any applications

and re-sign any licenses on that platform.

You can always use the rlm_putenv() call in place of putenv(). rlm_putenv() takes the same parameters as putenv()

OpenSSL, which RLM uses to create and authenticate digital signatures on licenses, dynamically allocates some crypto tables the first time it is used in a program.

There are 2 OpenSSL api calls to free allocated memory: CRYPTO_cleanup_all_ex_data() and ERR_remove_state(). As such they are not part of the RLM API, but are used in conjunction with it if you really care about memory leak detection at program exit. In practice almost nobody does.

If you use multiple threads with RLM, then call ERR_remove_state(0) just before the thread exits (and before your main thread exits as well).

CRYPTO_cleanup_all_ex_data() frees OpenSSL data when your program is no longer going to use OpenSSL (and hence RLM). The problem with it is that it is irreversible – once you call it, you cannot use OpenSSL (or RLM) again in that run of the program. Hence RLM cannot call it in rlm_close(), because a program might well call rlm_init() again.

The only legitimate place to use CRYPTO_cleanup_all_ex_data() is right before the program exits, and then only for the purpose of keeping leak detectors quiet, not for any practical purpose.

Note that CRYPTO_cleanup_all_ex_data() is not thread-safe, so use it with caution. For that reason, and because some applications create multiple RLM handles, it’s not practical for RLM itself to call this routine as part of rlm_close(). But your application can call it if you wish.

So, in summary, call ERR_remove_state(0) at the end of every thread that uses RLM, and at the end of your program, call ERR_remove_state(0) followed by CRYPTO_cleanup_all_ex_data().

Example error message:

Exception in thread “main” java.lang.UnsatisfiedLinkError: no rlmXXX in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at com.reprisesoftware.rlm.RlmHandle.createHandle(RlmHandle.java:94 )
at com.reprisesoftware.rlm.RlmHandle.(RlmHandle.java:128 )
at net.dirtt.icelib.dirtt.wall.RLMClient.main(RLMClient.java:32)

You need to ensure that the rlmXXX shared object is in your path.

On Unix you may need to set LD_LIBRARY_PATH to point to the rlmXXX shared object

On Mac you may need to set DYLD_LIBRARY_PATH to point to the rlmXXX shared object

On Windows rlmXXX.dll needs to be in your PATH.

In order to create universal binaries for the macOS platform, use the ”lipo” command as follows:

% lipo -create -output universal_binary ppc_binary x86_binary//

Where:

• universal_binary is the output universal binary name
• ppc_binary is the input PPC architecture binary
• x86_binary is the input X86 architecture binary

In order to verify the architectures present in a binary called ”binary_name”, use:

% lipo -info binary_name

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.

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” can be found: here

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.