Dual RLM instance on License Server

Modified on Wed, 12 Aug at 2:54 PM

In some instances, a License server needs to be configured with to instances of RLM, usually for different software.

If configured with an explicit site licence server address, it essentially communicates TCP directly to that host:port from the start, so it never needs the UDP broadcast/reply path at all.

We can confirm that the UDP errors and subsequent successful licensing are two unrelated code paths,rather than a cause and effect:

What's happening is that RLM has two independent mechanisms running side by side, and only one of them matters for actual licence checkout:

TCP - this is the core protocol. RLM uses TCP so the server can check the connection independently of data sent from the application, unlike a license manager based on UDP or RPC calls, which would need the application to send data periodically. All licence checkouts, heartbeats and check-ins go over TCP to the port specified on the HOST/ISV line in the licence file (or via RLM_LICENSE/env var).
UDP (port 5053) - this is used purely for broadcast discovery. The -noudp option tells RLM not to bind the UDP port (5053) used for replying to broadcast messages from clients in RLM v10.0 and later. That mechanism exists so a client that hasn't been told which host:port to use can shout onto the local subnet and find a server that way.

From a licensing-functionality point of view, it's a false positive that isn't blocking or degrading checkouts.
The error itself is genuine: something is stopping RLM from binding or replying on UDP 5053.
The usual causations are:

Another process (or a second rlm.exe instance) already holding port 5053 "Port 5053 in use, waiting..." is the classic symptom of two RLM instances.
A Firewall or security layer blocking UDP traffic on that port.
Reprise notes that Symantec anti-virus blocks some rlm messages, which usually surfaces as network read errors, though that example is TCP.
UDP filtering behaves similarly https://reprisesoftware.com/resources/knowledge-base
Multiple NICs/subnets on the licence server confusing broadcast delivery.

Recommendation: if the client machines always connect via explicit host:port (which they clearly do, since checkout works), you can just start RLM with -noudp to stop it binding that port altogether

This will silence the errors rather than leaving a permanently "failing" service in the log.

If you do want broadcast discovery to work for other clients on the network, it's worth chasing down the port conflict or firewall rule instead of just suppressing it.