Appendix B. Troubleshooting Guide
Prev |  | Next

## Appendix B. Troubleshooting Guide

This appendix documents areas of FLEXlm that have given customers difficulty in the past. We hope it helps you debug problems you 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 to see if that program has the same problem as your application.

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

- What kind of machine is your license server running on? What version of the operating system? What machine and operating system is the application running on?

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

      strings <program> | grep -i copyright | grep -i flexlm

- What error or warning messages appear in the log file? Did the server start correctly? Look for a message such as:

      	server xyz started for: feature1 feature2.

- What is the output from running lmstat -a?

- Are you running other products which are also licensed by FLEXlm? Are you using a combined license file or separate license files?

- Are you using redundant servers (multiple SERVER lines in your license file)?

### Problem Description Format

Each problem is presented in three parts:

Symptom: |  | A description of the problem.
Cause: |  | 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.

## FLEXlm Troubleshooting List

### Hostid Problems

Symptom: |  | When I run the license manager on my machine, it tells me it is the wrong hostid.
Cause: |  | 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 1) you are trying to run the license server on a different machine from the machine the file was made for; 2) the hostid of the machine you are running on changed (for example, the HP ID module was moved, or the CPU board was replaced); 3) 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: |  | The application program (or lmstat) can't connect to the server to check out a license.
Cause: |  | The FLEXlm routines in the application are unable to make a TCP connection to the server and port specified in the license file. Possible reasons for this are: 1) the wrong license file is being referenced by the application program; 2) the server machine specified in the license file is down; 3) the vendor daemon specified in the license file is not running; 4) the hostname in the license file is not recognized by the system; 5) the network between the client machine and the server machine is down; 6) 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: |  | 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 rsh or rlogin, 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. If you have the FLEXlm v4.0 utilities, try lmdiag.
Symptom: |  | The application program is able to connect from some machines but not from others.
Cause: |  | You are running a v1.5 license server on a machine with two Ethernet boards.
Solution: |  | There is a bug in FLEXlm v1.5 in which the license server only listens to the Ethernet address associated with the primary hostname on the system. The simplest solution is to get an upgraded license server from your software vendor (you can run a new license server and still keep running the old application software). Alternatively, you can ask your software vendor for a different license file and run your license daemon on a different machine with a single Ethernet board. If this is not possible, you may be able to modify your host tables to direct all FLEXlm requests to the active port on the machine.
Symptom: |  | The application program (or lmstat) gets the error can't read data when attempting to connect to the license server.
Cause: |  | The program is able to find the server, but it is not getting the expected data. The most likely cause for this is that you are running a newer application program than the vendor daemon.
Solution: |  | Check the version of the application program. Verify that it is using the expected license file. Check the version of the vendor daemon program referred to by the license file (look at the log file for that daemon).

## Other Client Problems

Symptom: |  | When I run my application program (or vendor daemon), I get the error bad code or inconsistent encryption code.
Cause: |  | Possible causes for this are 1) the license file was modified (either the hostid on a SERVER line or anything on the FEATURE line was changed); 2) 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”). 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.
Cause: |  | 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: |  | When I run the vendor daemon on my VMS system, I get the error message socket bind: permission denied (13).
Cause: |  | 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.
Cause: |  | `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: 1) there is no executable at the location referred to by the license file (and printed out in the log file); 2) 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); 3) there was an error building the executable, and it can not be run; 4) 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). whatis 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: |  | The license server keeps reporting “lost lock” errors in the log file and exiting.
Cause: |  | The lockfile (normally placed in /usr/tmp) 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: 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 ), then kill any remaining vendor daemons (try a simple kill, if that fails then try kill -9) and start one fresh copy of `lmgrd`. 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.

Prev | Table of Contents | Next
Appendix A. The Daemon Log File |  | Appendix C. Hostids for FLEXlm-Supported Machines