Chapter 7. Configuring License Daemons

lmgrd

The purpose of lmgrd is to:

  • start and maintain all the vendor daemons, listed in the DAEMON lines of the license file, and

  • refer application checkout (or other) requests to the correct vendor daemon.

lmgrd is a standard component of FLEXlm that neither requires nor allows for vendor customization. The license daemon does allow the license file location and the server-to-server connection timeout interval to be set by the end-user. These options are set by command line arguments when starting lmgrd. The command line for lmgrd is:

lmgrd [-2 ] [-2 -p] [-b] [-c license_file] [-l logfile]
  [-s timestamp_interval] [-t timeout_interval] [-x lmdown|lmremove ]
  [-v] [-z] [-f finder_file]

where:  

is the:

-2 

Use the FLEXlm v2.x startup arguments.

-p -2 

Restricts usage of lmdown, lmreread, and lmremove to a FLEXlm administrator who is by default root. If there is a UNIX group called, “lmadmin” then use is restricted to only members of that group. If root is not a member of this group, then root does not have permission to use any of the above utilities. (Default: no license administrator required).

-b 

Specifies that the pre-v2.0 vendor daemon startup is to be used. When this option is present, FLEXlm v1.x and v2.1 vendor daemons can be controlled by the same lmgrd. If you have v2.0 and v2.1 vendor daemons, DO NOT use the -b switch. v2.1 and later vendor daemons can be started either with or without the -b switch. (-b is the default in FLEXlm v3.0).

license_file 

pathname to the license file. (default: /usr/local/flexlm/licenses/license.dat on UNIX systems, or C:\FLEXLM\LICENSE.DAT on Windows and Windows NT systems).

-l logfile 

Debug log file produced by the daemons. (default: stdout)

-s timestamp_interval 


logfile time stamp interval, in minutes (default: 360 minutes).

timeout_interval 


time interval (in seconds) during which daemons must complete connections to each other. The default value is 10 seconds. A longer value may be desirable if the daemons are being run on busy systems and/or a very heavily loaded network.

-x lmdown|lmremove 


disable lmdown or lmremove commands.

-z 

Run in the foreground. lmgrd runs in the background by default.

-v 

Prints lmgrd's version number and copyright and exits.

-f finder_file 

With this option, lmgrd is run as a license finder. See Section “The License Finder (lmgrd -f)”.

-app 

Run lmgrd as an application from Windows NT console. This option is Windows NT only.


Note: The license file pathname can also be specified by setting the environment variable LM_LICENSE_FILE to the file's pathname. The -c path specification will override the setting of LM_LICENSE_FILE.


No lmgrd on VMS

The VMS version of FLEXlm does not use lmgrd, so clients connect directly with the vendor daemons. This implies that each vendor daemon is started independently in the system startup command file. The command line for starting a daemon is:

daemon_name [-c license_file_path] [-l log_file_path]

where:  

is the:

daemon_name  

name of the daemon.

license_file_path  

an alternate license file, if the LM_LICENSE_FILE environment variable is not set or if you want to override the setting of LM_LICENSE_FILE.

log_file_path  

an optional log file name. If this option is not selected, the logging information will be written to the screen.

The default license file on VMS is SYS$COMMON:[SYSMGR]flexlm.dat. You can set a new default in the vendor daemon by editing ls_vendor.c and changing the value of the (char *) variable default_license_file to be the pathname you wish for the default license file for your daemon. The end-user's license administrator can still override this setting with either the “-c” command-line option, and the end-user can set their LM_LICENSE_FILE environment variable.


Note: On VMS, the SYSNAM and SYSLCK privileges are required to run the daemons.


Starting lmgrd on Windows NT

lmgrd can be started as an application from the Windows NT console with the –app option. For example:

D:\flexlm> lmgrd -app -c my_lic.dat

Alternatively, lmgrd can be installed as a service on a Windows NT system so that it can be managed from the control panel on NT. To install lmgrd as a service, use the INSTALL.EXE command provided by FLEXlm. For example:

D:\flexlm> install d:\flexlm\lmgrd.exe

Note that the full pathname to lmgrd.exe must follow the install command. You must also make sure that the full path name including drive letter for your vendor daemon is specified correctly in your license file, c:\flexlm\license.dat. FLEXlm Windows NT DLL, lmgr32.dll, must also be in the system's DLL search path.

After INSTALL.EXE is run successfully, lmgrd is installed as a Windows NT service and will be started automatically each time your system is booted. To start lmgrd right after running INSTALL.EXE without rebooting your system, you may use the Service Icon from the Windows NT control panel. Look for FLEXlm Licensing Service from the dialogue box after you double click on the Service icon.

To remove lmgrd from the registered service list, simple type install remove. If you wish to customize the INSTALL program, the source code and makefile for INSTALL.EXE is included in the UTILS directory.

When lmgrd.exe is installed as a service on your system, you may use the following procedure to set the license file path for lmgrd by updating the system registry:

  1. Install lmgrd.exe as a service as described previously.

  2. Run Registry Editor, system32\regedt32.exe

    • Select HKEY_LOCAL_MACHINE:SYSTEM:
      CurrentControlSet:Control:Session Manager:Environment

    • From the menu bar, select Edit and then 'Add Value'

    • When the Add Value dialog box is displayed, enter LM_LICENSE_FILE as Value Name, and select REG_SZ as Data Type. Click OK.

    • At this point, the String Editor dialog box should appear, enter the full path to the license file that you wish to select. Click OK.

    • Exit Registry Editor.

  3. Shutdown your system and restart. lmgrd.exe should now be using the selected license file. To verify this, you can view lmgrd.log in the system32 directory.

Pre FLEXlm v2.0 Startup Arguments

The startup arguments for vendor daemons changed between FLEXlm v1.x and v2.0. If you are running a configuration with a mixture of v1.x and v2.x vendor daemons, then you will need to use the –b option (Note: this is the default in FLEXlm v3.0).

Privileged License Administration Commands

If the “-2 -p” startup argument is used to lmgrd, then the user who issues an lmdown, lmreread, or lmremove command must be a “license administrator”. A license administrator is:

  • a member of the “lmadmin” group, or, if no lmadmin group exists,

  • a member of group 0.

The License Finder (lmgrd -f)

The license finder provides license file path information to FLEXlm clients so that your end-users' license administrator does not have to set LM_LICENSE_FILE environment variables for each user. The license finder provides a single license file path to all clients. On the client side, the name of the license file is determined using the following algorithm:

  1. Looks for the environment variable FLEXLM_USE_FINDER (which can be set to any value)

  2. If (1) fails, looks for the environment variable LM_LICENSE_FILE

  3. If (1) succeeds, or (2) fails, looks for the “license finder”:

    • Uses port “FLEXLM” from the services map; if not present it uses port 744 (the “official” FLEXlm port)

    • Attempts to connect to this port on flexlm_license_finder, flexlm_license_finder2, flexlm_license_finder3 in order. Connect timeout is fixed at 2 seconds. This is done with TCP/IP. No broadcasts are involved. (For debugging, the connect timeout can be modified by setting the FLEXLM_FINDER_TIMEOUT environment variable to an integer). If the lookup of flexlm_license_finder fails, then the remainder of this step is skipped.

    • If it can connect to any license finder, it gets the license file path from the finder.

  4. Uses the default license file if (1) (2) and (3) fail.

Starting the license finder

To start the license finder, execute the following command on the node flexlm_license_finder (and optionally flexlm_license_finder2 and flexlm_license_finder3):

lmgrd -f finder_file

where:  

is the:

finder_file 

license finder file

lmgrd, when it is operating as a license finder (“-f finder_file” option), will ONLY processes the finder-specific messages, and sends the license file path back to the client. This lmgrd will NOT start any vendor daemons or process any other client request. This functionality is delivered in lmgrd so that you do not have to ship a separate executable.

The “finder file” format

The “finder file” format is:

DATA lfpath license_file_path1[:license_file_path2]

for example:

DATA lfpath /usr/local/flexlm/licenses/license.dat:1234@host2

where:  

is the:

license_file_path1...n 


full path to or the port@host address of a license file or files


Note: This format will be extended in a later release of FLEXlm to allow specification of paths that are specific to particular users, hosts, displays, and vendors.



Note: The license finder is not available on VMS systems.


Creating a New lmgrd Executable

All FLEXlm kits except for Windows NT contain the lmgrd library file liblmgrd.a. To create an lmgrd non-stripped executable, execute the following commands:

% cc -o lmgrd liblmgrd.a liblmgr_s.a liblmgr.a

Configuring Your Vendor Daemon

In order to build your vendor daemon you must supply the following information:

  • Your encryption seed(s).

  • The name of the daemon—VENDOR_NAME in lm_code.h.

If you use your own encryption routine, the routine must be specified in your vendor daemon.

Your vendor daemon can be configured by editing ls_vendor.c, or by running the script CONFIG_DAEMON. (See Chapter 2, “Installing the Distribution Kit.”) On VMS and Windows NT systems, you must edit the file ls_vendor.c to configure the daemon.

CONFIG_DAEMON edits the files ls_vendor.c and lm_code.h. The fields illustrated and described in the following sections can be edited with any text editor or via CONFIG_DAEMON.

When you have completed the necessary edits to ls_vendor.c, the makefile will create an lmrandom and then your vendor daemon by first running the lmrandom program to randomize your daemon configuration information (for additional security). For Windows NT systems, you must follow procedures listed in “Example CONFIG_DAEMON Session” to properly configure your vendor daemon. A temporary file lsr_vendor.c is created with the randomized data. The source to lmrandom is provided on the kit so that you can customize the randomization, if you desire. One of the functions of lmrandom is to remove the vendor name from the daemon executable file; the daemon name is constructed at run-time.


Note: In FLEXlm v2.4 and later, the CONFIG_DAEMON script only prompts for the daemon name, one set of encryption seeds, and the vendor keys. This is done to simplify installation when all the defaults are desired. If you wish to specify all the daemon options, use the “-x” option to CONFIG_DAEMON, which will cause it to prompt for all options as in prior FLEXlm versions.

Following are the ls_vendor.c variables.

Daemon Name

To insert your vendor daemon name, the lmrandom program takes the built-in vendor_name variable from lm_code.h and creates 10 single char variables with each character of your vendor name. Your daemon name no longer appears in the vendor daemon as a character string (from FLEXlm v2.4 on) until the daemon is running.


Note: In place of the lockfile used on UNIX systems, VMS daemons set the process name to: <daemon name>_FLEXlm” (truncated to 15 characters). This means that the daemon name must not contain any characters that are illegal in a VMS process name. This restriction will be removed in a future version of FLEXlm, as FLEXlm is migrated to use the VMS lock manager in place of the process name.


default_license_file (VMS only)

This variable is set to the pathname of the (new) default license file, if the software vendor desires to override the FLEXlm default of:

SYS$COMMON:[SYSMGR]FLEXLM.DAT.

ls_compare_vendor_on_increment

int ls_compare_vendor_on_increment = 0; /* Compare vendor-defined */

INCREMENT lines are combined if the following is true:

  • The feature names match

  • The feature versions match

  • Any node-lock hostid, if present, matches

  • Optionally, the vendor-defined strings match

ls_compare_vendor_on_increment gives you control whether an INCREMENT line will require the vendor string to match in order to pool its licenses. If set to a non-zero value, then the vendor string must match; if 0, then no comparison is done on the vendor string.

ls_compare_vendor_on_upgrade

int ls_compare_vendor_on_upgrade = 0; /* Compare vendor-def fields */

Prior to FLEXlm v3.0, UPGRADE lines were assigned to a FEATURE/INCREMENT line if the following was true:

  • The feature names match

  • The FEATURE/INCREMENT version is >= FROMVERSION and < TOVERSION

  • Any node-lock hostid, if present, matches

  • Optionally, the vendor strings match

ls_compare_vendor_on_upgrade gives you control whether an UPGRADE line will require the vendor string to match in order to upgrade another license. If set to a non-zero value, then the vendor string must match; if 0, then no comparison is done on the vendor string.

ls_conn_timeout

int ls_conn_timeout = MASTER_WAIT; /* How long to wait for a connection */

ls_conn_timeout is the amount of time (in seconds) that vendor daemons will wait for connections from vendor daemons on other nodes when using redundant servers. It should normally not be changed. This parameter has no effect on VMS versions of FLEXlm.

ls_crypt_case_sensitive

int ls_crypt_case_sensitive = 0; /* Is license key case-sensitive? */

If you have written your own encryption routine, and the output code from it is case-sensitive, set ls_crypt_case_sensitive to a non-zero value.

ls_daemon_periodic

void (*ls_daemon_periodic)() = 0; /* Vendor-defined periodic call in daemon */

If you set the function pointer “ls_daemon_periodic” in ls_vendor.c to one of your functions, this function will be called approximately once per minute in the vendor daemon's main processing loop. You must insure that the .o file for this routine specified in ls_vendor.c is linked into your vendor daemon.

ls_do_checkroot

int ls_do_checkroot = 0; /* Perform check that we are running on the real root */

To require that your vendor daemon be running on a filesystem which has its root directory as the “real” root directory of the disk, set this option. This prevents an end-user from cloning part of the UNIX file hierarchy and executing the daemon with a chroot command. If this were done, the vendor daemon locking would be bypassed and the user could run as many copies of your vendor daemon as he desired.

Theft by using chroot is considered to be an obscure, difficult kind of theft. The user has to have root permission, and setting up a phony / directory is a non-trivial task. It requires that the necessary parts of the OS from /etc, /dev, /bin, etc. be copied into this phony / directory, and is an ongoing administrative hassle.


Note: The check performed by ls_do_checkroot will FAIL on a diskless node. This prevents diskless nodes from acting as license servers. Globetrotter Software does NOT recommend running license daemons on diskless nodes, but if you choose to support this, you will need to set ls_do_checkroot to 0. For complete security, set ls_do_checkroot to 1. For minimization of confusion and support calls when your customers are running on diskless nodes, set ls_do_checkroot to 0.


ls_dump_send_data

int ls_dump_send_data = 0; /* Set to non-zero value for debug output */

This variable controls the debug output of transmitted daemon data. It should normally be left set to 0.

ls_enforce_startdate

int ls_enforce_startdate = 1; /* Enforce start date in features */

To use the start date present in the feature line, set ls_enforce_startdate to a non-zero value.

See also

ls_infilter

int (*ls_infilter)() = 0;

To install a vendor-defined checkin filtering routine, initialize ls_infilter with a pointer to your routine. The checkin filter is called with no parameters. If it returns 0, the current checkin is aborted; a return of 1 allows the current checkin to continue. If the filter aborts the operation (returns 0), then it should set the error code, lc_get_errno(), appropriately.

To obtain the parameters of the current checkin call, use the ls_get_attr() call described in “Vendor daemon Support Routines”.

ls_incallback

int (*ls_incallback)() = 0;

To install a vendor-defined checkin callback routine, initialize ls_incallback with a pointer to your routine. The checkin callback is called with no parameters, and the return value is unused. The checkin callback routine is called after the checkin is performed.

To obtain the parameters of the current checkin call, use the ls_get_attr() call described in “Vendor daemon Support Routines”.

ls_min_lmremove

int ls_min_lmremove = 120; /* Minimum amount of time (seconds) that a...

The lmremove utility could be used to bypass the license count for a feature if an end-user were to run lmremove on each user as soon as he had checked out a license. ls_min_lmremove makes the lmremove utility ineffective for a certain period of time after a user connects to the daemon (120 seconds by default).

See also

ls_minimum_user_timeout

int ls_minimum_user_timeout = 900; /* Minimum user inactivity timeout (seconds)

This is the minimum value (in seconds) that an end-user can set the feature's TIMEOUT value. An attempt to set a timeout less than ls_minimum_timeout will result in the minimum value being set. If ls_minimum_user_timeout is set to 0, then the user TIMEOUT option is disabled.

See also

ls_read_wait

int ls_read_wait = 10; /* How long to wait for solicited reads */

This variable controls how long the vendor daemon will wait for a connection to be completed with another vendor daemon. The default is 10 seconds. If your daemon supports a large number of features, you may need to increase this value, since the remote daemon's feature initialization can happen during this timeout interval.

ls_outfilter

int (*ls_outfilter)() = 0;

To install a vendor-defined checkout filtering routine, initialize ls_outfilter with a pointer to your routine. The checkout filter is called with no parameters. If it returns 0, the current checkout is aborted; a return of 1 allows the current checkout to continue.

If the filter aborts the operation (returns 0), then it should set the error code appropriately with lc_set_errno(). The general-purpose error code LM_CHECKOUTFILTERED is used for checkout requests that are filtered, if no other FLEXlm error is appropriate.

To obtain the parameters of the current checkout call, use the ls_get_attr() call described in “Vendor daemon Support Routines”.

ls_show_vendor_def

int ls_show_vendor_def = 0; /* If non-zero, the vendor daemon will send...

FLEXlm v2.4 allows your client to send a vendor-defined checkout string to the daemon on each checkout request. If ls_show_vendor_def is non-zero, this data will appear in lc_userlist() calls, and hence, in lmstat output. If you use this vendor-defined checkout data and wish for your users to be able to view it with lmstat, then set ls_show_vendor_def to 1.

ls_tell_startdate

int ls_tell_startdate = 1; /* Tell the user if it is earlier than start date */

To inform the user that a feature's start date is later than the system date, set ls_tell_startdate to a non-zero value. If ls_tell_startdate is 0, then the feature will not be enabled in the daemon, and no warning message will appear in the log file.

See also

ls_use_featset

int ls_use_featset = 0; /* Use the FEATURESET line from the license file */

To require the FEATURESET line in the license file, set ls_use_featset to a non-zero value.

ls_use_all_feature_lines

int ls_use_all_feature_lines = 0; /* Use ALL copies of feature lines that are...

Globetrotter Software discourages your use of this option, which has been made unnecessary and obsolete by the new INCREMENT and UPGRADE features. The ls_use_all_feature_lines option will cause your vendor daemon to process every FEATURE line in the license file as INCREMENT lines.

With ls_use_all_feature_lines set to a non-zero value, any old feature lines which you may have shipped will now be “legal”, so, for example, if you had shipped a customer a feature line with a count of 5, then upgraded them with a new line with a count of 7, they would now be able to use 12 licenses.

Some restriction on INCREMENT lines existed for FLEXlm v2.61. These restrictions are removed in FLEXlm v3.0.

ls_user_init1

void (*ls_user_init1)() = 0;

To install an initialization routine that runs before normal vendor daemon initialization, initialize ls_user_init1 with a pointer to your routine.

ls_user_init2

void (*ls_user_init2)() = 0;

To install an initialization routine that runs after normal vendor daemon initialization, initialize ls_user_init2 with a pointer to your routine and make sure an object file with this function is linked with your vendor daemon.

ls_vendor_msg

char *(*ls_vendor_msg)() = 0;

To add support for sending messages from your client code to the daemon (with lc_vsend()), initialize ls_vendor_msg with a pointer to your routine which will process the message and create the reply for the client. ls_vendor_msg() is called with a single parameter—the character string sent by the client. It should create a reply message and return a pointer to it. The message string will be unused the next time that ls_vendor_msg() is called, so the use of a single static char array in ls_vendor_msg() is appropriate. Make sure this an object file with this routine is linked with your vendor daemon.

See also

ls_user_crypt

char *(*ls_user_crypt)() = 0;

To use your own encryption routine, initialize ls_user_crypt with a pointer to your routine, and make sure an object file with this routine is linked with your vendor daemon.

ls_user_lockfile

char *user_lockfile = (char *)NULL;

The vendor daemons use a lock file to prevent multiple copies from running on a server host. By default, this lock file is named /usr/tmp/lockDAEMON, where DAEMON is the name from the DAEMON line. On some new systems, the default is /usr/tmp/.flexlm/.lockDAEMON. If user_lockfile is NULL, or points to a null string, the default lock file will be used.

In FLEXlm v3.0, the date on the lock file is updated every 6 hours to make it less likely for cron jobs to remove it.

If you wish to change the location of the lock file, set user_lockfile to the new location. Be sure to use a full pathname for this file (i.e. the pathname should start with “/”) otherwise, multiple vendor daemons could be run from different directories.

Vendorkeys and Vendor Encryption Seeds

VENDORCODE vendorkeys[] =.....

Example from lm_code.h:

/*
* VENDOR's private encryption seed — must be changed by user
* vendor should make up unique 32-bit hex numbers.
*/ 
#define ENCRYPTION_CODE_1 0x87654321
#define ENCRYPTION_CODE_2 0x12345678
/*
 *      FLEXlm vendor keys
 */ 
#define VENDOR_KEY1 0xe7503c03
#define VENDOR_KEY2 0x75811bed
#define VENDOR_KEY3 0xb8ea89c8
#define VENDOR_KEY4 0xc9a1b6d3
#define VENDOR_KEY5 0xc5dda903

The ENCRYPTION_CODEs are to be made up by the FLEXlm developer; the VENDOR_KEYS are supplied by Globetrotter Software when you purchase or upgrade FLEXlm.

CONFIG_DAEMON edits lm_code.h (or you can edit it manually) with the encryption seeds and vendor keys that you specified for your daemon. When your vendor daemon comes up, it checks all feature lines that specify its daemon name. If the license key in the license file is valid for any feature lines that the daemon checks, and the hostid is correct, then the vendor daemon sets the number of licenses to the value in the license file. All components of FLEXlm must share the same lm_code.h, where the VENDORCODE is specified. This encryption seed is the unique part of your daemon, so it is wise to

  • keep it confidential

  • make sure the encryption seeds are unique numbers you have made up.

Each entry in the VENDORCODE array consist of a pair of 32-bit vendor-defined encryption seed values and a set of five 32-bit Globetrotter Software supplied FLEXlm Vendor Keys. The two 32-bit vendor-defined encryption seeds should be set to any values that do not contain long strings of either 0 or 1 bits (e.g. do not use 0x5 or 0xffffff3f). The FLEXlm Vendor Keys supplied by Globetrotter Software enable various portions of the FLEXlm software to run. Both the first set of vendor-defined encryption seeds and the FLEXlm Vendor Keys will be defined in the include file lm_code.h by CONFIG_DAEMON.


Note: The encryption seeds that you use in your lc_init() call must be the same as the first set of encryption seeds in the vendorkeys array. Otherwise, a “Bad encryption handshake with daemon” error will result from a checkout request.



Note: Only the two encryption seeds, which you the vendor define, affect the licenses you create. The FLEXlm vendor keys have no effect on the license files you create.


Building Your Vendor Daemon - UNIX Systems

To build your vendor daemon (assuming the FLEXlm kit is in /usr/license):

For binary kits:

% cd /usr/license/lmgr

(run CONFIG_DAEMON to edit ls_vendor.c and lm_code.h as above).

% make

For source kits:

Create a binary kit as described in Chapter 2, “Installing the Distribution Kit” then follow the directions for the binary kit.

If you have added initialization or callback routines, you can add the XTRAOBJS macro to your make, e.g.:

make XTRAOBJS="xxx.o yyy.o zzz.o"

where xxx.o, yyy.o, and zzz.o are the object files for your additional routines. Alternately, you could modify the makefile to specify these objects.

Building Your Vendor Daemon - VMS Systems

To build your vendor daemon (assuming the FLEXlm kit is in [lmgr]):

$ set def [lmgr]

edit ls_vendor.c and lm_code.h to select your options and enter your vendor keys and encryption seeds.

$ @make

If you have added initialization or callback routines, you can edit make.com to add your new object files.

Building Your Vendor Daemon - Windows NT Systems

To build your vendor daemon (assuming the FLEXlm kit is in C:\LMGR):

C:> cd \lmgr\utils
C:> nmake /f lmrandom.mak
C:> cd \lmgr\vendor
C:> lmrandom < ls_vendo.c > lsr_vend.c
C:> nmake /f vendor.mak
C:> ren vendor.exe your_vendor_daemon_name.exe

Vendor daemon Support Routines

To aid in the development of the filter/callback functions, a new vendor daemon routine is available:

ls_get_attr(attr, &value)

where:  

is the:

attr 

an attribute specified in ls_attr.h

value 

(char *) - the value of the attribute.

ls_get_attr() operates in the same manner as lc_get_attr(). ls_get_attr() allows you to retrieve the values of the feature name, user, host, display, etc. for use in your filtering function.

The ls_checkout() vendor daemon routine is available for use in daemon filter routines:

ls_checkout(feature, ndesired, wait, who, version, server, dup_sel, linger, key, 0,0);

where:  

is the:

(char *) feature 

feature desired

(char *) ndesired 


Number of licenses

(char *) wait 

“Wait until available” flag (if == '1', the request will be queued if a license is not available.

(CLIENT_DATA *) who 


the user

(char *) version 

Feature's version number

(SERVERNUM) server 


Server requesting the checkout

(char *) dup_sel  


Duplicate license selection criteria

(char *) linger 

How long license is to linger

(char *) key 

License key from feature line

Return: 0 -> checkout not available, > 0 -> checkout done, < 0 -> request queued


Note: ls_get_attr() can be used to retrieve all the parameters that ls_checkout() requires.


Redundant License Servers

FLEXlm supports a set of three licenses servers to be used in a redundant manner. If any of two of the three license servers are up and running, the system is functional and hands out its total complement of licenses (Two out of three license servers is referred to as a “quorum”). To generate a license file that uses redundant servers, simply specify three servers when you create your license. Note that the use of two license servers is not recommended, since a license file with two servers would require that you always had both running.


Note: The VMS version of FLEXlm does not support redundant servers.

When redundant servers are started, they elect a master, which performs all licensing operations. The other one or two servers are there to provide a secure licensing mechanism in the event of hardware failure or in case the server node needs to be rebooted. Should the master fail, if two servers are still running, one of the remaining two will be elected master, and licensing operations will continue.

The order of SERVER lines in the license file (for redundant servers) specifies the end-user's desired selection order for the master server node starting with FLEXlm v2.0. If the order of these lines does not agree, then FLEXlm uses alphabetical order to determine the master, and the following messages are generated in the log file:

6/26 11:00 (lmgrd) License File SERVER line order mismatch.
6/26 11:00 (lmgrd) Using alphabetical order 

If the server order does not match, the daemons will come up initially, but reconnection in the event of server node failure may not work, depending on which node fails and who was the master before the failure. If the automatic failover in the event of node failure is important, please ensure that the order of the server lines is consistent on all server nodes.

When only two of the three license server machines are up, it is possible for the client to experience a timeout before connecting to the license server. Specifically, if the first license server in the license file is down, the client will timeout before attempting to connect to the second server in the license file. This timeout is set to 10 seconds by default, so there will be a 10-second delay before the license is granted. If the first server is to be down for a while, the order of the SERVER lines in the license file which the client reads could be changed to avoid this timeout. n