troubleshooting

This page documents areas of FLEXlm that have given customers difficulty in the past. We hope it helps you debug any problems you might experience at your site.

General Debugging Hints

The following are tips for debugging:

  • When you start the license server (lmgrd) be sure that you direct the output into a log file where you can examine it. The log file often contains useful information. You should examine it when you have a problem, and be prepared to answer questions about it when you talk to a support person.
  • If the license server appears to have started correctly (which you should be able to determine from the log file), try running 'lmstat -a' and 'lmdiag' to see if that program has the same problem as your application.
  • If your application is FLEXlm v4.1 or later (v5 on Windows), you can use the FLEXLM_DIAGNOSTICS environment variable. Set FLEXLM_DIAGNOSTICS to 1 or 2. (2 gives more information than 1, in particular, the feature name that was denied.)

  • When you talk to a support person, you should be prepared to answer the following questions:

    1. What kind of machine is your license server running on?
    2. What version of the operating system?
    3. What machine and operating system is the application running on?

    4. What version of FLEXlm does the program use? Use the 'lmver' script, or, on UNIX, execute the following command on your lmgrd, vendor daemon, and application:

      • strings <program> | grep Copy

      Alternatively, 'lmgrd -v' gives the version, and this works with the vendor daemon also.

    5. What error or warning messages appear in the log file?

    6. Did the server start correctly? Look for a message such as:

      • server xyz started for: feature1 feature2
    7. What is the output from running 'lmstat -a'?
    8. Are you running other products which are also licensed by FLEXlm?
    9. Are you using a combined license file or separate license files?
    10. Are you using redundant servers (multiple SERVER lines in your license file)?

FLEXLM_DIAGNOSTICS

Available only with applications using FLEXlm v4.1 or higher for Unix, and v5.0 or higher with Windows. Also, applications may choose not to provide this functionality.

FLEXLM_DIAGNOSTICS is an environment variable that will cause the application to produce diagnostic information when a checkout is denied. The format of the diagnostic information may change over time.

To set FLEXLM_DIAGNOSTICS, on Unix:

 

csh:% setenv FLEXLM_DIAGNOSTICS 1 
sh:$ FLEXLM_DIAGNOSTICS=1; export FLEXLM_DIAGNOSTICS

 

On Windows 3.1 and 95, add the following line to C:\AUTOEXEC.BAT:

 

SET FLEXLM_DIAGNOSTICS=1

 

On Windows NT, go to the System Control Panel applet to change the global environment, adding FLEXLM_DIAGNOSTICS to 1.

On Unix, the diagnostic output goes to stderr.

On Windows, if the application is v5.11 or higher, the output is a file in the current directory called 'flexnnn.log', where nnn is the application's process ID.

If the application is v5.0, the output file is called 'flex_err.log'.

FLEXLM_DIAGNOSTICS - Level 1 Content

If FLEXLM_DIAGNOSTICS is set to 1, then the standard FLEXlm error message will be presented, plus a complete list of license files that the application tried to use. For example:

 

% setenv FLEXLM_DIAGNOSTICS 1
FLEXlm checkout error: Cannot find license file (-1,73:2) 
No such file or directory license file(s): 
/usr/myproduct/licenses/testing.dat license.dat

 

FLEXLM_DIAGNOSTICS - Level 2 Content

If FLEXLM_DIAGNOSTICS is set to 2, then, in addition to level 1 output, the checkout arguments are presented. For example:

 

% setenv FLEXLM_DIAGNOSTICS 2FLEXlm checkout error: 
No such feature exists (-5,116:2) No such file or directory license file(s): 
/usr/myproduct/licenses/testing.dat license.dat
lm_checkout("f1", 1.0, 1, 0x0, ..., 0x4000)

 

Note that the error message actually contains 2 separate problems, which both occurred during the checkout: there's no such feature in the license it did find, and it was unable to find the other license file, which is what produces the message 'No such file or directory'.

Following is a description of the arguments to lm_checkout()

lm_checkout(feature_name, version, nlic, queue_flag, ..., dupgroup_mask)

feature_name:

  • the requested feature

version:

  • requested version. The license file must contain a version >= the requested version.

nlic:

  • number of licenses requested. Usually 1.

queue_flag:

  • If 0, no queueing If 1, queue for license (`blocking' queue) If 2, queue for licenses, but return to application (`non-blocking' queue)

dupgroup_mask

  • Indicates duplicate grouping, also called license sharing. User, host and display are as shown by lmstat -a.

FLEXLM_DIAGNOSTICS - Level 3 Content (FLEXlm v6 or later only)

If FLEXLM_DIAGNOSTICS is set to 3, then, in addition to level 1 and 2 output, if a checkout is successful, information is printed explaining how the license was granted:

 

% setenv FLEXLM_DIAGNOSTICS 3

 

application1

 

Checkout succeeded: f0/14263EAEA8E0 
License file: ./servtest.lic
No server used

 

application2

 

Checkout succeeded: f1/BC64A7B120AE
License file: @localhost
License Server: @localhost

 

application3

 

Checkout succeeded: f1/BC64A7B120AE
License file: servtest.lic
License Server: @speedy

 

Note that the feature name and license key are printed, along with the license file location (or hostname if @host were used) and hostname of the server, where applicable.

FLEXlm Troubleshooting List

Problem Description Format

Each problem is presented in three parts:

Symptom:

A description of the problem.

 

Description:
A discussion of what causes the problem described in the 'Symptom' section.

Solution:
Instructions on how to solve the problem.

You can scan through the list of problems to find any which appear to relate to your concerns. In order to solve your problem, you may have to use all or some of the solutions listed here.

Hostid Problems

Symptom:

When I run the license manager on my machine, it tells me it is the wrong hostid.

Description:

The vendor daemon checks the hostid listed on the SERVER line in the license file; if it does not match the hostid of the machine it is running on, this message will be printed. Possible causes include:

  • you are trying to run the license server on a different machine from the machine the file was made for;
  • the hostid of the machine you are running on changed (for example, the dongle hostid was moved (Windows), or the CPU board was replaced);
  • the hostid in the license file was modified.

Solution:

Verify that the hostid of the machine on which the vendor daemon (or node locked client program) is being run matches the hostid specified in the license file (on the SERVER line for the vendor, or on the FEATURE line for a node locked client). You can run the 'lmhostid' program to see what FLEXlm thinks the hostid is. You may not modify the hostid in the license file. If the hostid of your server machine changes, you will have to get a new license file from your software vendor.

Connection Problems

Symptom:

When using a floating license on Windows 7 the TASKING tools may become slow.

Description:

When using a floating license on Windows 7 the tools may become slow, depending on the network configuration. This issue was detected in a network with multiple domains. This is caused by the hostname lookup in FLEXlm.

Solution:

Either one of the following changes in the windows network configuration let the problem disappear:

  • Disable Netbios (Network connection, select "Internet Protocol (TCP/IP)", then Properties, Advanced; on the WINS tab, select Disable NetBIOS over TCP/IP)
  • Specify a default DNS suffix (Network connection, select "Internet Protocol (TCP/IP)", then Properties, Advanced; on the DNS tab add the "DNS suffix for this location", for example "yourcompany.com" )

Symptom:

The application program (or lmstat) can't connect to the server to check out a license.

Description:

  • the wrong license file is being referenced by the application program;
  • the server machine specified in the license file is down;
  • the vendor daemon specified in the license file is not running;
  • the hostname in the license file is not recognized by the system;
  • the network between the client machine and the server machine is down;
  • You are mixing FLEXlm v1.5 (or earlier) and v2.1 (or later) vendor daemons in one license file, and have run lmgrd without the -b command line option; 7) TCP is not running on your machine.

Solution:

The lmdiag utility is designed primarily to debug this problem, so first, try lmdiag. Verify that the application is using the proper license file. Verify that specified server machine is up and reachable by executing another command that uses TCP, such as telnet, from the client to the server. Verify that the vendor daemon is running (you can use ps on the server to look for it). Examine the license log file to see if any problems are reported, particularly messages indicating that the vendor daemon has quit. Run 'lmstat -a' from the server machine to verify that the vendor daemon is alive. Run 'lmstat -a' from the client machine to verify the connection from client to vendor daemon across the network. Try using 'telnet hostname portnum' where hostname and portnum are the same as on the SERVER line in your license file.

Symptom:

I have a floating license. Upon trying to build my project first thing that happens is that an attempt is made to establish a dial-up connection with my internet provider. This I cancel as I have no reason for wanting to dial-up but having done that EDE reports the following error message:

 

protection error, invalid host (-9,57:10061).

 

Description:

For a floating license it is required that you have a network. When launching either of the TASKING tools they themselves will attempt to connect to the server using the adapter as listed in you windows network settings. You will find that in this case you only have a dial-up adapter and not a network card i.e. you don't have a network. As you don't have a network there is no need for a floating license and a node-locked license would've been more appropriate.

Solution:

Contact your TASKING reseller to obtain the correct license.

Other Client Problems

Symptom:

After launching lmgrd the TASKING daemon reports:

 

wrong hostid, exiting (expected 1fcfb73d/001083FED461, got 0/" ")

 

Description:

The permissions for '/dev/lan0' are incorrect.

Solution:

Please refer to the Flexera website.

Symptom:

When I run my application program (or vendor daemon), I get the error "bad code or inconsistent encryption code".

Description:

Possible causes for this are

  • the license file was modified (either the hostid on a SERVER line or anything on the FEATURE line was changed);
  • the vendor used the wrong version of his license creation program to generate your license file (or there is a bug in that process).

Solution:

You may not modify the license file (except for specific fields, see Chapter 2, 'The License File' on page 7). If you need to change something in your license file, you must get a new license file from your software vendor.

Symptom:

When the second user tries to check out a license, the vendor daemon prints an error concerning Parameter mismatch in the log file and refuses the license.

Description:

The most likely cause of this problem is that you are simultaneously trying to run two different versions of the application program, and the software vendor has not specifically set up the new version for this kind of compatibility. Check the license server log file for a comm version mismatch warning message; this indicates that someone is running an older client than the license server daemon, lmgrd.

Solution:

Run only the new version of the application (or only the old version).

Other Server Problems

Symptom:

My license server does not start on Windows 7.

Description:

On Windows 7, the license server does not start when configured to run as a service. You may receive one of the following error messages:

  • "The service did not respond to the start or control request in a timely fashion."
  • "The FLEXlm License manager does not respond in a timely manner."
  • "Server Start Failed. The Server May Already Be Running!"
  • "StartService: unknown error."

However, starting the license manager via the command line does work. This is caused by lmgrd.exe which does not completely comply with the requirements for a service running on Windows 7.

Solution:

To solve this:

  • contact TASKING for a download of lmgrd for Microsoft Windows 32-bit, x86.
  • rename the existing lmgrd.exe to something else, and put the new lmgrd.exe instead

Now you should be able to start the license server using the Services Control Panel of Windows 7.

To be able to use LMTOOLS to control the license server, you'll need to update LMTOOLS as well:

  • contact TASKING for a download of lmtools for Microsoft Windows 32-bit, x86.
  • rename the existing lmtools.exe to something else, and put the new lmtools.exe instead

Note: the 32-bits version of lmgrd and lmtools work fine on Windows 7 64-bit.

Symptom:

When I run the vendor daemon on my VMS system, I get the error message "socket bind: permission denied (13)".

Description:

The daemon needs to bind the socket address in order to be able to listen for connections from clients. This is done in the system name table, so it requires the SYSNAM privilege.

Solution:

Run the daemon in a process with the SYSNAM privilege set.

Symptom:

When I start up lmgrd, it says execl failed on my vendor daemon.

Description:

lmgrd uses 'execl' to start each vendor daemon running. If there is a problem starting the vendor daemon, this message is output to the log file. This error is typically caused by one of the following:

  • there is no executable at the location referred to by the license file (and printed out in the log file);
  • the executable does not have the proper permissions to be run (the file does not have the 'x' bit set, or one of the directories in the path is not readable);
  • there was an error building the executable, and it can not be run;
  • the executable is for a different machine architecture.

Solution:

Verify that the path to the vendor daemon is absolute (i.e. starts with a slash character, and that it points to the executable program itself, not the containing directory (for FLEXlm v1.5). Ensure that the file exists by doing an 'ls -l' of the vendor daemon filename(s) specified in the log file. Make sure you do this as the same user that started lmgrd. Verify that the file is executable. Note that if you are running as root and using an NFS-mounted filesystem, the relevant protection bits are the 'other' bits (not the 'user' bits), even if the file is owned by root. Do a whatis on the file (if your system has that program). what should tell you the file is an executable for the machine you are trying to run it on. Run the vendor daemon directly from the command line. If the vendor daemon is properly linked, it will tell you that it must be run from lmgrd; if it crashes or fails to execute, then it is not properly linked.

Symptom:

We have a floating TASKING license. Along with the TASKING daemon, we also use a daemon of another party. It is for this reason that we decided to use two individual license files each referring to appropriate daemon. The setup is as follows below:

  • c:\flexlm - flexlm directory
  • c:\flexlm\vendorx\vendorx.dat - vendorx license
  • c:\flexlm\tasking\tasking.dat - tasking license

Everything appears to have been set up such as for example LM_LICENSE_FILE to point to both licenses yet upon launching lmgrd the following error message is logged: MULTIPLE "TASKING" servers running

This is strange because the process list indicates the contrary i.e. there is no TASKING daemon running whatsoever. This is also confirmed when we attempt to build any of our projects. All tools report the following: cannot connect to license server

Description:

When the TASKING daemon is launched it will create a temporary file called 'tasking' to prevent itself from launching more than once. In this case, you created a folder carrying the exact same name of the temporary file which caused it to abort its own launch.

Solution:

To make it launch you will have to choose a folder name other than 'tasking' to store your license file. Please make sure that you also adapt the paths as stored in the TASKING license file and LM_LICENSE_FILE. After these changes, lmgrd must be relaunched and this time the TASKING daemon should launch as well.

Symptom:

The license server keeps reporting lost lock' errors in the log file and exiting.

Description:

The lockfile (normally placed in '/usr/tmp' on UNIX, 'C:\flexlm' on Windows NT, 'SYS:\SYSTEM\FLEXLM' on Netware) is being removed by someone else. There could be another daemon running, or the license administrator (or a script he set up) could have deleted the file.

Solution:

Check to see if there is more than one copy of the daemon running. On UNIX use a command like 'ps -aux | grep vendorname' to search for it. Check for more than one lmgrd running as well, since it will restart your vendor daemon when it is killed. If more than one lmgrd is running, kill them all (using the 'kill' command, not 'kill -9' on UNIX or the Control Panel Services dialog on Windows/NT), then kill any remaining vendor daemons (on UNIX, try a simple 'kill', if that fails then try 'kill -9' the lmgrd and all vendor daemons) and start one fresh copy of lmgrd. On UNIX, check to see if there is a shell script running that cleans out '/tmp' (or '/usr/tmp'). If so, try modifying it so that it does not delete zero-length files.