FLEXLM - TROUBLESHOOTING

TROUBLESHOOTING

This page doc­u­ments areas of FLEXlm that have given cus­tomers dif­fi­cul­ty in the past. We hope it helps you debug any prob­lems you might expe­ri­ence at your site.

General Debugging Hints

The fol­low­ing are tips for debug­ging:

  • When you start the license serv­er (lmgrd) be sure that you direct the out­put into a log file where you can exam­ine it. The log file often con­tains use­ful infor­ma­tion. You should exam­ine it when you have a prob­lem, and be pre­pared to answer ques­tions about it when you talk to a sup­port per­son.
  • If the license serv­er appears to have start­ed cor­rect­ly (which you should be able to deter­mine from the log file), try run­ning ‘lmstat -a’ and ‘lmdi­ag’ to see if that pro­gram has the same prob­lem as your appli­ca­tion.
  • If your appli­ca­tion is FLEXlm v4.1 or later (v5 on Win­dows), you can use the FLEXLM_DIAGNOSTICS envi­ron­ment vari­able. Set FLEXLM_DIAGNOSTICS to 1 or 2. (2 gives more infor­ma­tion than 1, in par­tic­u­lar, the fea­ture name that was denied.)
  • When you talk to a sup­port per­son, you should be pre­pared to answer the fol­low­ing ques­tions:
    1. What kind of machine is your license serv­er run­ning on?
    2. What ver­sion of the oper­at­ing sys­tem?
    3. What machine and oper­at­ing sys­tem is the appli­ca­tion run­ning on?
    4. What ver­sion of FLEXlm does the pro­gram use? Use the ‘lmver’ script, or, on UNIX, exe­cute the fol­low­ing com­mand on your lmgrd, ven­dor dae­mon, and appli­ca­tion:
      • strings <pro­gram> | grep Copy
      Alter­na­tive­ly, ‘lmgrd -v’ gives the ver­sion, and this works with the ven­dor dae­mon also.
    5. What error or warn­ing mes­sages appear in the log file?
    6. Did the serv­er start cor­rect­ly? Look for a mes­sage such as:
      • serv­er xyz start­ed for: feature1 feature2
    7. What is the out­put from run­ning ‘lmstat -a’?
    8. Are you run­ning other prod­ucts which are also licensed by FLEXlm?
    9. Are you using a com­bined license file or sep­a­rate license files?
    10. Are you using redun­dant servers (mul­ti­ple SERVER lines in your license file)?

FLEXLM_DIAGNOSTICS

Avail­able only with appli­ca­tions using FLEXlm v4.1 or high­er for Unix, and v5.0 or high­er with Win­dows. Also, appli­ca­tions may choose not to pro­vide this func­tion­al­i­ty.

FLEXLM_DIAGNOSTICS is an envi­ron­ment vari­able that will cause the appli­ca­tion to pro­duce diag­nos­tic infor­ma­tion when a check­out is denied. The for­mat of the diag­nos­tic infor­ma­tion may change over time.

To set FLEXLM_DIAGNOSTICS, on Unix:

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

On Win­dows 3.1 and 95, add the fol­low­ing line to C:\AUTOEXEC.BAT:

SET FLEXLM_DIAGNOSTICS=1

On Win­dows NT, go to the Sys­tem Con­trol Panel applet to change the glob­al envi­ron­ment, adding FLEXLM_DIAGNOSTICS to 1.

On Unix, the diag­nos­tic out­put goes to stderr.

On Win­dows, if the appli­ca­tion is v5.11 or high­er, the out­put is a file in the cur­rent direc­to­ry called ‘flexnnn.log’, where nnn is the appli­ca­tion’s process ID.

If the appli­ca­tion is v5.0, the out­put file is called ‘flex_err.log’.


FLEXLM_DIAGNOSTICS - Level 1 Con­tent

If FLEXLM_DIAGNOSTICS is set to 1, then the stan­dard FLEXlm error mes­sage will be pre­sent­ed, plus a com­plete list of license files that the appli­ca­tion tried to use. For exam­ple:

% 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 Con­tent

If FLEXLM_DIAGNOSTICS is set to 2, then, in addi­tion to level 1 out­put, the check­out argu­ments are pre­sent­ed. For exam­ple:

% 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 mes­sage actu­al­ly con­tains 2 sep­a­rate prob­lems, which both occurred dur­ing the check­out: there’s no such fea­ture in the license it did find, and it was unable to find the other license file, which is what pro­duces the mes­sage ‘No such file or direc­to­ry’.


Fol­low­ing is a descrip­tion of the argu­ments to lm_checkout()

lm_checkout(feature_namever­sionnlicqueue_flag, …, dupgroup_mask)

feature_name:

  • the request­ed fea­ture

ver­sion:

  • request­ed ver­sion. The license file must con­tain a ver­sion >= the request­ed ver­sion.

nlic:

  • num­ber of licens­es request­ed. Usu­al­ly 1.

queue_flag:

  • If 0, no queue­ing If 1, queue for license (‘block­ing’ queue) If 2, queue for licens­es, but return to appli­ca­tion (‘non-block­ing’ queue)

dupgroup_mask

  • Indi­cates dupli­cate group­ing, also called license shar­ing. User, host and dis­play are as shown by lmstat -a.

FLEXLM_DIAGNOSTICS - Level 3 Con­tent (FLEXlm v6 or later only)

If FLEXLM_DIAGNOSTICS is set to 3, then, in addi­tion to level 1 and 2 out­put, if a check­out is suc­cess­ful, infor­ma­tion is print­ed explain­ing how the license was grant­ed:

% 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 fea­ture name and license key are print­ed, along with the license file loca­tion (or host­name if @host were used) and host­name of the serv­er, where applic­a­ble.

FLEXlm Troubleshooting List

Prob­lem Descrip­tion For­mat

Each prob­lem is pre­sent­ed in three parts:

Symp­tom:

A descrip­tion of the prob­lem.

Descrip­tion:
A dis­cus­sion of what caus­es the prob­lem described in the ‘Symp­tom’ sec­tion.

Solu­tion:
Instruc­tions on how to solve the prob­lem.

You can scan through the list of prob­lems to find any which appear to relate to your con­cerns. In order to solve your prob­lem, you may have to use all or some of the solu­tions list­ed here.

Hostid Problems

Symp­tom:

When I run the license man­ag­er on my machine, it tells me it is the wrong hostid.

Descrip­tion:

The ven­dor dae­mon checks the hostid list­ed on the SERVER line in the license file; if it does not match the hostid of the machine it is run­ning on, this mes­sage will be print­ed. Pos­si­ble caus­es include:

  • you are try­ing to run the license serv­er on a dif­fer­ent machine from the machine the file was made for;
  • the hostid of the machine you are run­ning on changed (for exam­ple, the don­gle hostid was moved (Win­dows), or the CPU board was replaced);
  • the hostid in the license file was mod­i­fied.

Solu­tion:

Ver­i­fy that the hostid of the machine on which the ven­dor dae­mon (or node locked client pro­gram) is being run match­es the hostid spec­i­fied in the license file (on the SERVER line for the ven­dor, or on the FEATURE line for a node locked client). You can run the ‘lmhostid’ pro­gram to see what FLEXlm thinks the hostid is. You may not mod­i­fy the hostid in the license file. If the hostid of your serv­er machine changes, you will have to get a new license file from your soft­ware ven­dor.

Connection Problems

Symp­tom:

When using a float­ing license on Win­dows 7 the TASKING tools may become slow.

Descrip­tion:

When using a float­ing license on Win­dows 7 the tools may become slow, depend­ing on the net­work con­fig­u­ra­tion. This issue was detect­ed in a net­work with mul­ti­ple domains. This is caused by the host­name lookup in FLEXlm.

Solu­tion:

Either one of the fol­low­ing changes in the win­dows net­work con­fig­u­ra­tion let the prob­lem dis­ap­pear:

  • Dis­able Net­bios (Net­work con­nec­tion, select “Inter­net Pro­to­col (TCP/IP)”, then Prop­er­ties, Advanced; on the WINS tab, select Dis­able Net­BIOS over TCP/IP)
  • Spec­i­fy a default DNS suf­fix (Net­work con­nec­tion, select “Inter­net Pro­to­col (TCP/IP)”, then Prop­er­ties, Advanced; on the DNS tab add the “DNS suf­fix for this loca­tion”, for exam­ple “yourcompany.com” )

Symp­tom:

The appli­ca­tion pro­gram (or lmstat) can’t con­nect to the serv­er to check out a license.

Descrip­tion:

  • the wrong license file is being ref­er­enced by the appli­ca­tion pro­gram;
  • the serv­er machine spec­i­fied in the license file is down;
  • the ven­dor dae­mon spec­i­fied in the license file is not run­ning;
  • the host­name in the license file is not rec­og­nized by the sys­tem;
  • the net­work between the client machine and the serv­er machine is down;
  • You are mix­ing FLEXlm v1.5 (or ear­li­er) and v2.1 (or later) ven­dor dae­mons in one license file, and have run lmgrd with­out the -b com­mand line option; 7) TCP is not run­ning on your machine.

Solu­tion:

The lmdi­ag util­i­ty is designed pri­mar­i­ly to debug this prob­lem, so first, try lmdi­ag. Ver­i­fy that the appli­ca­tion is using the prop­er license file. Ver­i­fy that spec­i­fied serv­er machine is up and reach­able by exe­cut­ing anoth­er com­mand that uses TCP, such as tel­net, from the client to the serv­er. Ver­i­fy that the ven­dor dae­mon is run­ning (you can use ps on the serv­er to look for it). Exam­ine the license log file to see if any prob­lems are report­ed, par­tic­u­lar­ly mes­sages indi­cat­ing that the ven­dor dae­mon has quit. Run ‘lmstat -a’ from the serv­er machine to ver­i­fy that the ven­dor dae­mon is alive. Run ‘lmstat -a’ from the client machine to ver­i­fy the con­nec­tion from client to ven­dor dae­mon across the net­work. Try using ‘tel­net host­name port­num’ where host­name and port­num are the same as on the SERVER line in your license file.


Symp­tom:

I have a float­ing license. Upon try­ing to build my project first thing that hap­pens is that an attempt is made to estab­lish a dial-up con­nec­tion with my inter­net provider. This I can­cel as I have no rea­son for want­i­ng to dial-up but hav­ing done that EDE reports the fol­low­ing error mes­sage:

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

Descrip­tion:

For a float­ing license it is required that you have a net­work. When launch­ing either of the TASKING tools they them­selves will attempt to con­nect to the serv­er using the adapter as list­ed in you win­dows net­work set­tings. You will find that in this case you only have a dial-up adapter and not a net­work card i.e. you don’t have a net­work. As you don’t have a net­work there is no need for a float­ing license and a node-locked license would’ve been more appro­pri­ate.

Solu­tion:

Con­tact TASKING to obtain the cor­rect license.

Other Client Problems

Symp­tom:

After launch­ing lmgrd the TASKING dae­mon reports:

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

Descrip­tion:

The per­mis­sions for ‘/dev/lan0’ are incor­rect.

Solu­tion:

Please refer to the Flex­era web­site.


Symp­tom:

When I run my appli­ca­tion pro­gram (or ven­dor dae­mon), I get the error “bad code or incon­sis­tent encryp­tion code”.

Descrip­tion:

Pos­si­ble caus­es for this are

  • the license file was mod­i­fied (either the hostid on a SERVER line or any­thing on the FEATURE line was changed);
  • the ven­dor used the wrong ver­sion of his license cre­ation pro­gram to gen­er­ate your license file (or there is a bug in that process).

Solu­tion:

You may not mod­i­fy the license file (except for spe­cif­ic fields, see Chap­ter 2, ‘The License File’ on page 7). If you need to change some­thing in your license file, you must get a new license file from your soft­ware ven­dor.


Symp­tom:

When the sec­ond user tries to check out a license, the ven­dor dae­mon prints an error con­cern­ing Para­me­ter mis­match in the log file and refus­es the license.

Descrip­tion:

The most like­ly cause of this prob­lem is that you are simul­ta­ne­ous­ly try­ing to run two dif­fer­ent ver­sions of the appli­ca­tion pro­gram, and the soft­ware ven­dor has not specif­i­cal­ly set up the new ver­sion for this kind of com­pat­i­bil­i­ty. Check the license serv­er log file for a comm ver­sion mis­match warn­ing mes­sage; this indi­cates that some­one is run­ning an older client than the license serv­er dae­mon, lmgrd.

Solu­tion:

Run only the new ver­sion of the appli­ca­tion (or only the old ver­sion).

Other Server Problems

Symp­tom:

My license serv­er does not start on Win­dows 7.

Descrip­tion:

On Win­dows 7, the license serv­er does not start when con­fig­ured to run as a ser­vice. You may receive one of the fol­low­ing error mes­sages:

  • “The ser­vice did not respond to the start or con­trol request in a time­ly fash­ion.”
  • “The FLEXlm License man­ag­er does not respond in a time­ly man­ner.”
  • “Serv­er Start Failed. The Serv­er May Already Be Run­ning!”
  • “Start­Ser­vice: unknown error.”

How­ev­er, start­ing the license man­ag­er via the com­mand line does work. This is caused by lmgrd.exe which does not com­plete­ly com­ply with the require­ments for a ser­vice run­ning on Win­dows 7.

Solu­tion:

To solve this:

  • con­tact TASKING for a down­load of lmgrd for Microsoft Win­dows 32-bit, x86.
  • rename the exist­ing lmgrd.exe to some­thing else, and put the new lmgrd.exe instead

Now you should be able to start the license serv­er using the Ser­vices Con­trol Panel of Win­dows 7.

To be able to use LMTOOLS to con­trol the license serv­er, you’ll need to update LMTOOLS as well:

  • con­tact TASKING for a down­load of lmtools for Microsoft Win­dows 32-bit, x86.
  • rename the exist­ing lmtools.exe to some­thing else, and put the new lmtools.exe instead

Note: the 32-bits ver­sion of lmgrd and lmtools work fine on Win­dows 7 64-bit.


Symp­tom:

When I run the ven­dor dae­mon on my VMS sys­tem, I get the error mes­sage “sock­et bind: per­mis­sion denied (13)”.

Descrip­tion:

The dae­mon needs to bind the sock­et address in order to be able to lis­ten for con­nec­tions from clients. This is done in the sys­tem name table, so it requires the SYSNAM priv­i­lege.

Solu­tion:

Run the dae­mon in a process with the SYSNAM priv­i­lege set.


Symp­tom:

When I start up lmgrd, it says execl failed on my ven­dor dae­mon.

Descrip­tion:

lmgrd uses ‘execl’ to start each ven­dor dae­mon run­ning. If there is a prob­lem start­ing the ven­dor dae­mon, this mes­sage is out­put to the log file. This error is typ­i­cal­ly caused by one of the fol­low­ing:

  • there is no exe­cutable at the loca­tion referred to by the license file (and print­ed out in the log file);
  • the exe­cutable does not have the prop­er per­mis­sions to be run (the file does not have the ‘x’ bit set, or one of the direc­to­ries in the path is not read­able);
  • there was an error build­ing the exe­cutable, and it can not be run;
  • the exe­cutable is for a dif­fer­ent machine archi­tec­ture.

Solu­tion:

Ver­i­fy that the path to the ven­dor dae­mon is absolute (i.e. starts with a slash char­ac­ter, and that it points to the exe­cutable pro­gram itself, not the con­tain­ing direc­to­ry (for FLEXlm v1.5). Ensure that the file exists by doing an ‘ls -l’ of the ven­dor dae­mon filename(s) spec­i­fied in the log file. Make sure you do this as the same user that start­ed lmgrd. Ver­i­fy that the file is exe­cutable. Note that if you are run­ning as root and using an NFS-mount­ed filesys­tem, the rel­e­vant pro­tec­tion 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 sys­tem has that pro­gram). what should tell you the file is an exe­cutable for the machine you are try­ing to run it on. Run the ven­dor dae­mon direct­ly from the com­mand line. If the ven­dor dae­mon is prop­er­ly linked, it will tell you that it must be run from lmgrd; if it crash­es or fails to exe­cute, then it is not prop­er­ly linked.


Symp­tom:

We have a float­ing TASKING license. Along with the TASKING dae­mon, we also use a dae­mon of anoth­er party. It is for this rea­son that we decid­ed to use two indi­vid­ual license files each refer­ring to appro­pri­ate dae­mon. The setup is as fol­lows below:

  • c:\flexlm - flexlm direc­to­ry
  • c:\flexlm\vendorx\vendorx.dat - ven­dorx license
  • c:\flexlm\tasking\tasking.dat - task­ing license

Every­thing appears to have been set up such as for exam­ple LM_LICENSE_FILE to point to both licens­es yet upon launch­ing lmgrd the fol­low­ing error mes­sage is logged: MULTIPLE “TASKING” servers run­ning

This is strange because the process list indi­cates the con­trary i.e. there is no TASKING dae­mon run­ning what­so­ev­er. This is also con­firmed when we attempt to build any of our projects. All tools report the fol­low­ing: can­not con­nect to license serv­er

Descrip­tion:

When the TASKING dae­mon is launched it will cre­ate a tem­po­rary file called ‘task­ing’ to pre­vent itself from launch­ing more than once. In this case, you cre­at­ed a fold­er car­ry­ing the exact same name of the tem­po­rary file which caused it to abort its own launch.

Solu­tion:

To make it launch you will have to choose a fold­er name other than ‘task­ing’ 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 dae­mon should launch as well.


Symp­tom:

The license serv­er keeps report­ing lost lock’ errors in the log file and exit­ing.

Descrip­tion:

The lock­file (nor­mal­ly placed in ‘/usr/tmp’ on UNIX, ‘C:\flexlm’ on Win­dows NT, ‘SYS:\SYSTEM\FLEXLM’ on Net­ware) is being removed by some­one else. There could be anoth­er dae­mon run­ning, or the license admin­is­tra­tor (or a script he set up) could have delet­ed the file.

Solu­tion:

Check to see if there is more than one copy of the dae­mon run­ning. On UNIX use a com­mand like ‘ps -aux | grep ven­dor­name’ to search for it. Check for more than one lmgrd run­ning as well, since it will restart your ven­dor dae­mon when it is killed. If more than one lmgrd is run­ning, kill them all (using the ‘kill’ com­mand, not ‘kill -9′ on UNIX or the Con­trol Panel Ser­vices dia­log on Windows/NT), then kill any remain­ing ven­dor dae­mons (on UNIX, try a sim­ple ‘kill’, if that fails then try ‘kill -9’ the lmgrd and all ven­dor dae­mons) and start one fresh copy of lmgrd. On UNIX, check to see if there is a shell script run­ning that cleans out ‘/tmp’ (or ‘/usr/tmp’). If so, try mod­i­fy­ing it so that it does not delete zero-length files.

Scroll to Top