Knowledge Center         Contents    Previous  Next    Index  
Platform Computing Corp.

Platform LSF Licensing

Contents

The LSF License File

You must have a valid license to run LSF. This section helps you to understand the types of LSF licenses and the contents of the LSF license file. It does not contain information required to install your license.

tip:  
To learn about licensing license a cluster that includes Windows hosts, see Using Platform LSF on Windows.

Evaluation (demo) license

You can use a demo license to install Platform LSF and get it running temporarily, then switch to the permanent license before the evaluation period expires with no interruption in service, as described in Installing a Permanent License.

Although there may be exceptions, a typical demo license:

Permanent license

Although there may be exceptions, a typical permanent license:

Enforcement of dual-core processor licenses on Linux

Dual-core processor hosts running Linux must be licensed by the lsf_dualcore_x86 license feature.

Each dual core processor requires one standard LSF license and one lsf_dualcore_x86 license.

Use lshosts -l to see the number of dual-core licenses enabled and needed. For example:

lshosts -l hostB
HOST_NAME:  hostB
type    model  cpuf  ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 PC6000 116.1   2      1  2016M  1983M 72917M      0    Yes      1      2        2

LICENSES_ENABLED: (LSF_Base LSF_Manager LSF_MultiCluster LSF_Sched_Fairshare 
LSF_Sched_Resource_Reservation LSF_Sched_Preemption LSF_Sched_Parallel 
LSF_Sched_Advance_Reservation LSF_DualCore_x86LICENSE CLASS NEEDED: Class(B), Multi-cores
... 

Enforcement of multicore processor licenses on Linux and Windows

Multicore hosts running Linux or Windows must be licensed by the lsf_dualcore_x86 license feature. Each physical processor requires one standard LSF license and num_cores-1 lsf_dualcore_x86 licenses. For example, a processor with 4 cores requires 3 lsf_dualcore_x86 licenses.

Use lshosts -l to see the number of multicore licenses enabled and needed. For example:

lshosts -l hostB
HOST_NAME:  hostB
type   model cpuf    ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 PC6000 116.1    2     1  2016M  1983M 72917M      0   Yes      1      4        2

LICENSES_ENABLED: (LSF_Base LSF_Manager LSF_MultiCluster LSF_Sched_Fairshare 
LSF_Sched_Resource_Reservation LSF_Sched_Preemption LSF_Sched_Parallel 
LSF_Sched_Advance_Reservation LSF_DualCore_x86LICENSE CLASS NEEDED: Class(B), Multi-cores
... 

Enforcement of grid license managment plugin licenses

The new license optimization features enabled by the grid license management plugin require the lsf_mv_grid_filter license feature.

The number of lsf_mv_grid_filter licenses should be at least the number of LSF License Scheduler licenses.

Banded licensing

You can use permanent licenses with restrictions in operating system and hardware configurations. These banded licenses have three classes, with the E-class licenses having no restrictions. Banded licenses support the following operating systems and hardware configurations:

License type
Supported operating systems
Processor
Physical memory
Physical processors/sockets
B-Class
Linux, Windows, MacOS
Intel X86/AMD64/EM64T
Up to and including 4 GB physical memory on a node
Up to and including 2 processors
S-Class
Linux, Windows, MacOS
Intel X86/AMD64/EM64T
Up to and including 16 GB physical memory on a node
Up to and including 4 processors
E-Class
Linux, Windows, MacOS
Intel X86/AMD64/EM64T
More than 16 GB physical memory on a node
More than 4 processors
All other LSF-supported operating systems
Intel X86/AMD64/EM64T
N/A
N/A
N/A
All other supported processors
N/A
N/A

In the LSF license file:

FEATURE lsf_manager lsf_ld 6.200 8-may-2008 2 ADE2C12C1A81E5E8F29C \        
VENDOR_STRING=Platform NOTICE=Class(S) 
FEATURE lsf_manager lsf_ld 6.200 8-may-2008 10 1DC2C1CCEF193E42B6DC \ 
VENDOR_STRING=Platform NOTICE=Class(E) 
Determining what licenses a host needs

Use lim -t and lshosts -l to see the license requirements for a host. For example:

lim -t hostA
Host Type             : NTX64
Host Architecture     : EM64T_1596
Physical Processors   : 2
Cores per Processor   : 4
Threads per Core      : 2
License Needed        : Class(B), Multi-core
Matched Type          : NTX64
Matched Architecture  : EM64T_3000
Matched Model         : Intel_EM64T
CPU Factor            : 60.0 
lshosts -l hostA
HOST_NAME:  hostA
type    model  cpuf  ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 PC6000 116.1  2    1    2016M  1983M  72917M  0     Yes       2      4       2
...
          LICENSE CLASS NEEDED: Class(B), Multi-cores
... 

Format of the demo license file

This is intended to familiarize you with the demo license file. You do not need to read this section if you are only interested in installing the license.

LSF licenses are stored in a text file. The default name of the license file is license.dat.

The license.dat file for an LSF license normally contains the same products defined in lsf.cluster.cluster_name.

The license.dat file for a demo license contains a FEATURE line for each LSF product. Each feature contains an expiry date and ends with the string DEMO.

For example:

FEATURE lsf_base lsf_ld 7.000 24-Oct-2008 100 DCF7C3D92A5471A12345 "Platform" DEMO 

The FEATURE line contains an encrypted key to prevent tampering.

A demo license does not require a server daemon or vendor daemon, so it does not contain SERVER or DAEMON lines, only FEATURE lines.

Example demo license file

The following is an example of a demo license file. This file licenses LSF 7, advance reservation, and Platform LSF Make. The license is valid until October 24, 2008.

Format of the permanent license file

A permanent license file has the same format as other products licensed with FLEXlm. If you are already familiar with FLEXlm license files, you can skip this section.

In addition to the information presented in the demo license file (see Format of the demo license file), the permanent license file includes the following:

Example permanent license file

The following is an example of a permanent license file.

The license server daemon is configured to run on hosta, using TCP port 1700. It allows 10 single-processor hosts to run Platform LSF 7 and Platform LSF Make, with no expiry date.

How LSF Permanent Licensing Works

This section is intended to give you a better understanding of how LSF licensing works in a production environment with a permanent license. It does not contain information required to install your license.

Platform LSF uses the FLEXlm license management product from GLOBEtrotter Software to control its licenses. LSF licenses are controlled centrally through the LSF master LIM.

FLEXlm license server

Permanent LSF licenses are managed by the FLEXlm license server daemon (lmgrd). The FLEXlm license server daemon runs on a license server host you choose (for failover purposes, the daemon can run on multiple hosts).

The lmgrd daemon starts the LSF vendor license daemon lsf_ld, which periodically keeps track of how many LSF licenses are checked out and who has them. Only one lsf_ld can run on a host. If lsf_ld stops running, lmgrd immediately stops serving LSF licenses to all LSF hosts.

The LIM on the LSF master hosts contacts the license server host to get the necessary LSF licenses. It then propagates licenses to all LSF server hosts and client hosts. Multiple LSF clusters can get licenses from the same license server host.

The TIMEOUT ALL parameter in the FLEXlm license option file changes timeout values, including how quickly the master host releases licenses during failover. LSF supports a minimum timeout value of 15 minutes. For information about how to configure the TIMEOUT ALL parameter, see the FLEXlm documentation.

LSF license checkout

Only the master LIM can check out licenses. No other part of LSF has any contact with the FLEXlm license server daemon. Once LIM on the master host identifies itself as the master, it reads the LSF_CONFDIR/lsf.cluster.cluster_name file to get the host information to calculate the total number of licenses needed. Most LSF software is licensed per CPU, not per host or per cluster, so multi-processor hosts require multiple LSF licenses.

After the cluster is properly licensed, the master LIM contacts the license server daemon periodically to confirm the availability of checked out LSF licenses.

LIM distributes the licenses needed this way:

  1. Calculate the total number of licenses needed for the master LIM.
  2. Before slave LIMs contact the master, calculate the total number of licenses needed for all LSF server hosts and check them out. When the slave LIMs start, they contact the master host to get the licenses they need.
  3. Check out licenses needed for client hosts listed in LSF_CONFDIR/lsf.cluster.cluster_name. If the license checkout fails for any host, that host is unlicensed. The master LIM tries to check out the license later.

LSF license grace period

If the master LIM finds the license server daemon has gone down or is unreachable, LSF has a grace period before the whole cluster is unlicensed. As long as the master LIM that originally received the licenses is not restarted or shut down, the LSF cluster can run up to 60 hours without licenses. If you reconfigure LSF after the license server daemon becomes unavailable, you lose the grace period and the cluster is unlicensed because the original LIM that carries the correct license information is killed and restarted during reconfiguration. This prevents LSF from becoming a single point of failure and enables LSF to function reliably over an extended period of time (for example, over a long weekend) should the license server daemon fail.

Unlicensed cluster

While LSF cannot contact a license server daemon, LSF commands are automatically resubmitted, not aborted.

Installing a Demo License

This section includes instructions for licensing LSF with a new demo license.

Most new users should follow the procedure under Install and license LSF for the first time.

If you already have LSF installed, see Install a demo license manually.

Install and license LSF for the first time

If LSF has never been installed before, you should install and license LSF in one step, using a demo license and the LSF installation program for UNIX, lsfinstall.

  1. Acquire your demo license before you install LSF.
  2. See Get a demo license.

  3. When you receive your license file, save it as license.dat.
  4. See Viewing and editing the license file.

  5. Install LSF using lsfinstall as described in Installing Platform LSF on UNIX and Linux. lsfinstall automatically sets up the LSF demo license.

Install a demo license manually

If you just need to update or replace an existing LSF license, see Updating a License.

If LSF is installed without a license file, or the license file is not properly installed, you can install a demo license manually.

  1. Acquire your demo license.
  2. See Get a demo license.

  3. When you receive your license file, save it as license.dat.
  4. See Viewing and editing the license file.

  5. Move the license file to a location where it can be shared.
  6. See Location of the LSF license file for a demo license.

  7. Set the LSF_LICENSE_FILE parameter to point to your license file.
  8. See LSF_LICENSE_FILE parameter.

  9. Start or restart LSF. This causes the license file to be read and the changes accepted by LSF:

Get a demo license

To get a demo license from Platform Computing or your Platform LSF vendor.

Location of the LSF license file for a demo license

For a demo license, each LSF host must be able to read the license file.

The installation program lsfinstall puts the LSF license file in a shared directory where it is available to all LSF hosts.

If you install the license manually, use either of the following methods to ensure that a license is available to all hosts:

Installing a Permanent License

This section includes instructions for licensing LSF with a new permanent license.

If you have not yet installed LSF, you can use a demo license to get started. See Installing a Demo License.

If you already have LSF, see Install a permanent license for the first time.

Install a permanent license for the first time

If you are switching from a demo license to a permanent license, follow these instructions to set up the permanent license. You can discard the old demo license; LSF cannot use both licenses at the same time.

If you just need to update an existing permanent license, see Updating a License.

  1. Acquire your permanent license.
  2. See Getting a permanent license.

  3. When you receive your license file, save it as license.dat.
  4. See Viewing and editing the license file.

  5. Edit the DAEMON line in the license file to point to the LSF vendor license daemon lsf_ld.
  6. The LSF vendor license daemon is installed in LSF_SERVERDIR (defined lsf.conf or set in your environment). For example:

    DAEMON lsf_ld /usr/share/lsf/lsf_62/7.0/sparc-sol2/etc/lsf_ld 
     

    The lsf_ld binary should be available to the FLEXlm server using this path.

  7. Verify that the LSF products enabled by the PRODUCTS line in LSF_CONFDIR/lsf.cluster.cluster_name are licensed by features in the license file.
  8. For example, if the PRODUCTS line contains:

    PRODUCTS=LSF_Make LSF_MultiCluster  
     

    then your license must include FEATURE lines such as:

    FEATURE lsf_make lsf_ld 7.000 1-jun-0000 10 DCF7C3D92A5471A12345 "Platform" FEATURE lsf_multicluster lsf_ld 7.000 1-jun-0000 10 4CF7D37944B023A12345 "Platform"

    If you do not have licenses for some products in the PRODUCTS line, contact Platform Computing or your Platform LSF vendor. To continue installing your permanent license, remove the unlicensed products from the PRODUCTS line.

    See Licensing LSF products and features.

  9. Make sure the file is in a location where it can be accessed by the license server daemons.
  10. See Location of the LSF license file for a permanent license.

  11. Set the LSF_LICENSE_FILE parameter to point to your license file.
  12. See LSF_LICENSE_FILE parameter.

  13. Start the license server daemon.
  14. See Start the license daemons.

  15. To allow the new permanent license to take effect, reconfigure the cluster:
  16. lsadmin reconfig 
    badmin mbdrestart 
    
  17. After the cluster starts, use the following commands to make sure LSF is up and running:
  18. lsid 
    bhosts 
    

Getting a permanent license

To install Platform LSF for production use, you must get a permanent license from Platform or your LSF vendor.

Platform creates a permanent license that is keyed to the license server host or hosts. Some host types have a built-in hardware host ID; on others, the hardware address of the primary LAN interface is used. For a permanent license to be created, you must supply a server host name and the hardware host identifier for each license server host at your site.

Send the following information to Platform Computing or your Platform LSF vendor.

Getting the FLEXlm license server host identifier

When an LSF license is managed by FLEXlm, you must provide a hardware host name and host identifier for the FLEXlm license server host at your site.

If you do not already use FLEXlm to manage other applications, you must choose a host as the FLEXlm license server host before you request your license. See Selecting a license server host.

Use the lmhostid command (normally located in LSF_SERVERDIR) to get the hardware identifier of your FLEXlm license server host. For example, run this command on the FLEXlm server host:

lmhostid
lmhostid - Copyright (C) 1989-1997 Globetrotter Software, Inc.
The FLEXlm host ID of this machine is "68044d20" 

In this example, send the code "68044d20" to Platform.

Viewing and editing the license file

Your LSF license should be a text file (normally named license.dat). Use any text editor such as vi or emacs to open a copy of your license file for viewing or editing.

For example,

If you can, make carriage returns visible, or view the text without word wrap. Although the lines might wrap when displayed on a screen, make sure each line in the text file has no extra characters. You can accidentally corrupt your license file if you view it or copy it from email, and then save it with hidden line breaks.

Do not try to modify lines or fields unless instructed to do so by Platform. You could corrupt the license. Do not combine demo license lines with permanent license lines. For more information about LSF license files, see Format of the demo license file and Format of the permanent license file.

Location of the LSF license file for a permanent license

For a permanent license, the FLEXlm license daemon lmgrd and the LSF vendor daemon lsf_ld must be able to read the LSF license file. You can put the license file on the license server host, or in a shared directory.

Daemons on the LSF master host do not need any access to the permanent license file.

LSF_LICENSE_FILE parameter

The LSF_LICENSE_FILE parameter in LSF_CONFDIR/lsf.conf points to the LSF license file.

The installation program lsfinstall configures the LSF_LICENSE_FILE parameter automatically for demo licenses only. You must set LSF_LICENSE_FILE manually if you do either of the following:

To configure LSF_LICENSE_FILE, specify the full path name to the license file. A permanent license file should also be visible to the FLEXlm license server host using the same path.

The value for LSF_LICENSE_FILE can be either of the following:

For example, after you run lsfinstall, the default setting is:

LSF_LICENSE_FILE can also be the name of the license server host and the port number used by lmgrd in the form port_number@host_name. For example, if your license file contains the line:

SERVER hosta 68044d20 1700 

LSF_LICENSE_FILE would be:

LSF_LICENSE_FILE="1700@hosta"  
FLEXlm default

If you installed FLEXlm separately from LSF to manage other software licenses, the default FLEXlm installation puts the license file in the following location: /usr/local/flexlm/licenses/license.dat

Troubleshooting

If this parameter points to an older or incorrect license key, correct the problem using one of these two methods:

Licensing LSF products and features

All LSF software requires a license. Some LSF features are enabled by the license file alone, but other products must also be included in the cluster configuration file, or the FEATURE line in the license file is ignored. However, if you already have the FEATURE line in your license file, you can install or enable the corresponding products later on.

The following strings are examples of what can be listed in the PRODUCTS line in the Parameters section of the lsf.cluster.cluster_name file, to indicate which LSF products that the cluster should run. This is not a comprehensive list of Platform product license names. Any valid Platform LSF license product name can be on the PRODUCTS line, according to which Platform products you've purchased:

If these products are listed in the cluster configuration, the LSF license must also include FEATURE lines for these products.

In addition, there are some "extra" licensed features that do not have a matching item in the PRODUCTS line. Do not remove features from your license unless instructed to do so by Platform. For example, the following strings are valid in the license file, but should not be used in the PRODUCTS line:

LSF client hosts are licensed per host, not per CPU, so there is no difference between licensing a single-processor host and a multi-processor host.

See Floating Client Licenses for information about configuring LSF floating clients.

FLEXlm license server host

A permanent LSF license is tied to the host ID of a particular license server host and cannot be used on another host.

If you are already running FLEXlm to support other software licenses, you can use the existing license server host to manage LSF also. In this case, you will add your Platform LSF license key to the existing FLEXlm license file.

If you are not already using FLEXlm, or prefer to administer LSF license management separately, you must choose a host to run the license daemons. See Selecting a license server host.

It is possible to run multiple license server hosts for failover purposes. See Multiple FLEXlm License Server Hosts.

Selecting a license server host

By reading this, you will gain the information needed to make an educated decision when selecting a license server host.

The FLEXlm license server daemon normally runs on one host. LSF tolerates failure of the license server daemon for up to 60 hours, as long as the master LIM is not restarted or shut down.

If you are installing a permanent license, choose a reliable host as the license server host to ensure that the LSF licenses are always available. LSF cannot run if it cannot contact the license server daemon. Although the license server host can be an LSF host, it is usually a host outside of the cluster. The license daemons create very little load, so they can be run on the host that is the dedicated file server for the Platform LSF software. This permits the licenses to be available whenever the LSF software is available.

You should not make the license server host the same as the master host for the cluster. If you do this, and the master host goes down, the backup master that takes over will not be able to check license tokens out from the license server daemon on the original master which has failed.

FLEXlm software for the license server host

Permanent (server-based) LSF licenses work with FLEXlm version 7.2 or later.

If your FLEXlm license server host is of the same host type as one or more LSF hosts, the FLEXlm software is included in the LSF distribution and automatically installed under LSF_SERVERDIR, which is a shared directory (so there is no requirement to copy any software to your FLEXlm license server host; just include LSF_SERVERDIR in your PATH environment variable on the license server host so that you can access the files and start the daemons).

If your FLEXlm license server host is a different host type, you do not need the complete LSF distribution. You can download just the FLEXlm software from Platform's FTP site, and copy it to any convenient location.

Updating a License

This section is intended for those who are updating an existing LSF license file.

To switch your demo license to a permanent license, see Installing a Permanent License.

To update a license:

  1. Contact Platform to get the license. See Requesting a new license.
  2. Update the license using one of the following procedures
remember:  
After updating an existing LSF license file or adding FLEXlm licenses, you must use lsadmin limrestart on the master LIM or lsadmin reconfig from any LIM to use the new licenses.

Requesting a new license

To update your license, contact Platform Computing or your Platform LSF vendor. Since you already have a license, you will only receive new lines to put into your existing file.

FEATURE LINES

To update your license file, LSF licenses are sent to you in the form of FEATURE license lines when you:

INCREMENT LINES

If you add hosts to your cluster and you already have an LSF product, licenses for the additional hosts are normally sent to you in the form of INCREMENT license lines.

Updating a license with FEATURE lines

FLEXlm only accepts one license key for each feature listed in a license file. If there is more than one FEATURE line for the same feature, only the first FEATURE line is used.

If you received one or more FEATURE lines, update your license by adding the lines to your existing license file.

  1. Edit your license.dat file using a text editor like vi or emacs.
  2. See Viewing and editing the license file.

  3. You should always have just one FEATURE line for each LSF product:
  4. If you want LSF 4.x and LSF 5.x clusters to share a license file, make sure your license includes the FEATURE line for lsf_batch version 4.x.
  5. Reconfigure LSF using either of the following LSF commands:

Update a license with INCREMENT lines

  1. If you received one or more INCREMENT lines, update your license by adding the lines to your existing license file.
  2. Edit your license.dat file using a text editor like vi or emacs.
  3. See Viewing and editing the license file.

  4. Always append an INCREMENT line, do not overwrite or delete existing license lines in the process.
  5. Reconfigure LSF using either of the following LSF commands:

FLEXlm Basics

This section is for users installing a permanent license, as FLEXlm is not used with demo licenses. Users who already know how to use FLEXlm will not need to read this section.

FLEXlm is used by many UNIX software packages because it provides a simple and flexible method for controlling access to licensed software. A single FLEXlm license server daemon can handle licenses for many software packages, even if those packages come from different vendors. This reduces the system's administration load, since you do not need to install a new license manager every time you get a new package.

Start the license daemons

FLEXlm uses license daemons to manage permanent licenses. For a brief description of FLEXlm and its license daemons, see FLEXlm license server.

This is a procedure that describes how to start the FLEXlm license daemons.

  1. Log on to the license server host as LSF administrator.
  2. important:  
    Do not run lmgrd as root.
  3. If you have an old lsf_ld running, run lmdown to kill it.
  4. You can only have one lsf_ld daemon running on a host.

  5. Run the lmgrd command in LSF_SERVERDIR to start the license server daemon:
  6. lmgrd -c /usr/share/lsf/lsf_62/conf/license.dat -l 
    /usr/share/lsf/lsf_62/log/license.log 
     

    The -c option specifies the license file (or license file list, if you have multiple license server hosts). For more information, see LSF_LICENSE_FILE parameter.

    The -l option specifies the debug log path. For more information, see FLEXlm log file.

    tip:  
    You should include LSF_SERVERDIR in your PATH environment variable. You may want to include the full command line in your system startup files on the license server host, so that lmgrd starts automatically during system reboot.

    See Checking the license server status to check the status of lmgrd.

Checking the license server status

If you are using a permanent LSF license, use the lmstat command to check the status of the license server daemon. This check can tell you whether or not your attempt to start your license server daemon succeeded. If your attempt failed, see lmgrd fails with message "Port already in use".

The lmstat command is in LSF_SERVERDIR. For example:

/usr/share/lsf/lsf_62/7.0/sparc-sol2/etc/lmstat 

Run lmstat -a -c LSF_LICENSE_FILE from the FLEXlm license server and also from the LSF master host. You must use the -c option of lmstat to specify the path to the LSF license file.

The output of lmstat gives the status of:

For example, depending on the LSF features installed, the output of the command should look something like the following:

lmstat -a -c $LSF_ENVDIR/license.dat 
lmstat - Copyright (C) 1989-1997 Globetrotter Software, Inc.
Flexible License Manager status on Fri 10/15/1999 13:23
 
License server status: 1711@hostA
    License file(s) on hostA: /usr/local/cluster1/mnt/conf/license.dat:
 
    hostA: license server UP (MASTER) v5.12
 
Vendor daemon status (on hostA):
 
    lsf_ld: UP v5.12
 
Feature usage info:
Users of lsf_base:  (Total of 50 licenses available)
 
  "lsf_base" v4.100, vendor: lsf_ld
  floating license
 
  root hostB /dev/tty (v3.0) (hostA/1711 401), start Thu 10/14 12:32, 20 licenses
  ... 

FLEXlm log file

Read this to familiarize yourself with the FLEXlm log file.

The FLEXlm license server daemons log messages about the state of the license server hosts, and when licenses are checked in or out. This log helps to resolve problems with the license server hosts and to track license use. The log file grows over time. You can remove or rename the existing FLEXlm log file at any time.

You must choose a location for the log file when you start the license daemon. If you already have FLEXlm server running for other products and Platform LSF licenses are added to the existing license file, then the log messages for FLEXlm should go to the same log file you set up for other products. If FLEXlm is dedicated to managing LSF licenses, you can put the FLEXlm log in the same directory as your other system logs, or in the /tmp directory.

License management utilities

FLEXlm provides several utility programs for managing software licenses. These utilities and their man pages are included in the Platform LSF software distribution.

Because these utilities can be used to shut down the FLEXlm license server daemon, and can prevent licensed software from running, they are installed in the LSF_SERVERDIR directory. For security reasons, this directory should only be accessible to LSF administrators. Set the file permissions so that only root and members of group 0 can use them.

LSF installs the following FLEXlm utilities in LSF_SERVERDIR:

lmcksum

Calculate check sums of the license key information

lmdown

Shut down the FLEXlm server

lmhostid

Display the hardware host ID

lmremove

Remove a feature from the list of checked out features

lmreread

Tell the license daemons to re-read the license file

lmstat

Display the status of the license server daemons and checked out licenses

lmver

Display the FLEXlm version information for a program or library

For complete details on these commands, see the FLEXlm man pages.

Multiple FLEXlm License Server Hosts

This section applies to permanent licenses only. Read this section if you are interested in the various ways you can distribute your licenses. This is valuable if you are interested in having some form of backup in case of failure. Compare with Selecting a license server host to make an educated decision.

Although it is not necessary, you may want to understand how the FLEXlm license server behaves prior to setting up your license server hosts. For a brief description on how FLEXlm works, see FLEXlm license server.

If you are concerned about the reliability of your license server host, you can distribute the LSF licenses across multiple FLEXlm license server hosts. If one license server host goes down, LSF will not lose all of the available licenses. There are two ways to configure multiple license server hosts:

Distributed license server hosts

Configuring multiple license server hosts is optional. It provides a way to keep LSF running if a license server host goes down. There are two ways to configure multiple license servers. This section describes distributed license server hosts. See Redundant license server hosts for information on the other configuration.

Distributing licenses over multiple server hosts provides a fallback, in case your license server daemons fail.

With this method, you run multiple license server daemons, each with its own license file. Each license file has a SERVER line keyed to the license server host it is assigned to. The cluster is partially licensed as long as any one license server daemon is running, and fully licensed when all license server daemons are running. When a license server host is unavailable, the licenses managed by that host are unavailable. You decide how many LSF licenses to put on each license server host.

Enable multiple license server hosts

See the procedures for installing and configuring a permanent license. There are a few differences when you use distributed license server hosts:

  1. See Getting a permanent license. You must obtain multiple license files, with your total number of licenses divided appropriately among the license server hosts. You must provide the following information for each license server host:
  2. See LSF_LICENSE_FILE parameter. Specify the location of all the licenses in LSF_LICENSE_FILE, not just one. Use a pipe (|) onUNIX and Linux or a colon (:) on Windows to separate each location. List the primary license server host first (the one you want LSF to contact first).
  3. See Start the license daemons. Start lmgrd on all license server hosts, not just one.
  4. To allow the new permanent licenses to take effect, reconfigure the cluster with the commands:
  5. lsadmin reconfig 
    badmin mbdrestart 
    

Redundant license server hosts

Configuring multiple license server hosts is optional. It provides a way to keep LSF running if a license server host goes down. There are two ways to configure multiple license servers. This section describes redundant license server hosts. See Distributed license server hosts for information on the second configuration.

A permanent license key is tied to a particular license server host with a specific host ID. If that host is down, the license service is not available and LSF becomes unlicensed if the master LIM is shut down or restarted.

To prevent down time, you can configure three hosts as license server hosts. The license server daemon (lmgrd) and LSF vendor license daemon (lsf_ld) run on each license server host. With three redundant server hosts, if any one host is down, the other two continue to serve licenses. If any two hosts are down, the license service stops.

Enable multiple license server hosts

See the procedures for installing and configuring a permanent license. There are a few differences when you use redundant license server hosts:

  1. See Getting a permanent license. You must obtain a license file that contains three SERVER lines. You must provide the following information for each license server host:
  2. See LSF_LICENSE_FILE parameter. Specify the location of all the licenses in LSF_LICENSE_FILE, not just one. Use a pipe (|) on UNIX and Linux or a colon (:) on Windows to separate each location. List the primary license server host first (the one you want LSF to contact first).
  3. See Start the license daemons. Start lmgrd on all license server hosts, not just one.
  4. To allow the new permanent licenses to take effect, reconfigure the cluster with the commands:
  5. lsadmin reconfig 
    badmin mbdrestart 
    

Partial Licensing

This section applies to permanent licenses. Read this if you have a cluster in which not all of the hosts will require licenses for the same LSF products. In this section, you will learn how to save money through distributing your licenses efficiently.

Not all hosts in the cluster need to be licensed for the same set of LSF products. For example, some hosts might be licensed only for Platform LSF Make, while others may also be licensed to run Platform MultiCluster. All hosts in the cluster remain licensed regardless of the license configuration of the rest of the cluster. If hosts become unavailable or new hosts are added, licenses are redistributed according to the new configuration.

This allows you to purchase only as many licenses as you need, rather than enabling the entire cluster for products that are only needed by a few hosts.

However, many LSF products do not support partial licensing. They must be enabled for the entire cluster, or not at all.

Setting priority for license distribution

This describes how to define the order your licenses are given out to hosts.

To enable LSF server hosts to run partially licensed LSF products, edit the Host section of LSF_CONFDIR/lsf.cluster.cluster_name and include the product names in the RESOURCES column for specific hosts. When the LSF cluster starts, the master LIM reads the lsf.cluster.cluster_name file and determines the LSF products that each host is licensed to use.

For a permanent license, the license manager retrieves the appropriate licenses for the cluster, and distributes the licenses to the hosts in the order they are listed in lsf.cluster.cluster_name. You can see the order in which licenses are distributed with the command lshosts.

Displaying licensed products

This describes how to view what products are licensed for any host in the cluster.

Use the lshosts -l command.

lshosts -l hostA 
HOST_NAME:  hostA
type model cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 PC6000 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: Not defined
RUN_WINDOWS:  (always open)

Licenses enabled: (LSF_Base LSF_Manager)


LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem   tmp2    nio console
     -   3.5     -    -     -     -    -    -     -     -     -      -      -     0.0 

Example of partial licensing

Here is an example that will allow you to better visualize the concept of partial licensing. Through this example, you can learn how to configure your hosts to use partial licensing.

Scenario

In the following configuration, the license file contains licenses for LSF, Platform LSF Make and Platform LSF MultiCluster. The licenses have the following distribution:

All three single-CPU hosts in the cluster are licensed for LSF, while hostA and hostC are licensed for Platform LSF Make. The hostB is explicitly licensed for Platform MultiCluster, and not for Platform LSF Make. The RESOURCES field in the Host section of lsf.cluster.cluster_name must contain the LSF products LSF_Base and LSF_Manager, in addition to LSF_MultiCluster. The rest of the licenses needed are enabled by

Configuration

The lsf.cluster.cluster_name file contains the following configuration:

Begin Parameters
PRODUCTS=LSF_Base LSF_Manager LSF_Make
End Parameters

Begin       Host
HOSTNAME  model     type    server  r1m  mem  swp  RESOURCES
hostA     DEFAULT   LINUX86  1       -    ()   ()  ()
hostB     DEFAULT   LINUX86  1        -    ()   ()  (LSF_Base LSF_Manager LSF_MultiCluster)
hostC     DEFAULT   LINUX86  1       -    ()   ()  ()
End     Host 
Cluster startup

At cluster startup, all hosts are running, and the lshosts -l command displays the following license distribution:

lshosts -l 

HOST_NAME:  hostA
type    model   cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 DEFAULT 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: Not defined
RUN_WINDOWS:  (always open)

: (LSF_Base LSF_Manager LSF_Make)

LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem
     -     -     -    -     -     -    -    -     -     -     -

HOST_NAME:  hostB
type    model   cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 DEFAULT 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: (LSF_Base LSF_Manager LSF_MultiCluster)
RUN_WINDOWS:  (always open)

LICENSES_ENABLED: (LSF_Base LSF_Manager)

LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem
     -     -     -    -     -     -    -    -     -     -     -

HOST_NAME:  hostC
type    model   cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 DEFAULT 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: Not defined
RUN_WINDOWS:  (always open)

LICENSES_ENABLED: (LSF_Base LSF_Manager)

LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem
     -     -     -    -     -     -    -    -     -     -     - 

All hosts are licensed for the appropriate products except hostC, which does not have Platform LSF Make because its license is already being used by hostA. However, hostC is still available to run LSF jobs.

Master host failover

If HostA becomes unavailable, HostB becomes master host. Now the lshosts -l command displays the following license distribution:

lshosts -l 

HOST_NAME:  hostA
type    model   cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 DEFAULT 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: Not defined
RUN_WINDOWS:  (always open)

LICENSES_ENABLED: (LSF_Client)

LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem
     -     -     -    -     -     -    -    -     -     -     -

HOST_NAME:  hostB
type    model   cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 DEFAULT 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: (LSF_Base LSF_Manager)
RUN_WINDOWS:  (always open)

LICENSES_ENABLED: (LSF_Base LSF_Manager)

LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem
     -     -     -    -     -     -    -    -     -     -     -

HOST_NAME:  hostC
type    model   cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server nprocs ncores nthreads
LINUX86 DEFAULT 116.1     2      1  2016M  1983M 72917M      0    Yes      1      1        2

RESOURCES: Not defined
RUN_WINDOWS:  (always open)

LICENSES_ENABLED: (LSF_Base LSF_Manager LSF_Make)

LOAD_THRESHOLDS:
  r15s   r1m  r15m   ut    pg    io   ls   it   tmp   swp   mem
     -     -     -    -     -     -    -    -     -     -     - 

Note that hostC has now picked up the available Platform LSF Make license that was originally held by hostA.

Floating Client Licenses

LSF floating client is valuable if you have a cluster in which not all of the hosts will be active at the same time. In this section, you will learn how to save money through distributing your licenses efficiently.

An LSF floating client license is a type of LSF license to be shared among several client hosts at different times. Floating client licenses are not tied to specific hosts. They are assigned dynamically to any host that submits a request to LSF. The number of licenses acts as a license pool for the cluster from which LSF clients can draw required licenses. Although floating client licenses are supported, LSF does not support floating server licenses.

Client hosts and floating client hosts

In LSF, you can have both client hosts and floating client hosts. The difference is in the type of license purchased.

If you purchased a regular (fixed) client license, LSF client hosts are static. The client hosts must be listed in lsf.cluster.cluster_name. The license is fixed to the hosts specified in lsf.cluster.cluster_name and whenever client hosts change, you must update it with the new host list.

If you purchased a floating client license, LSF floating client hosts are dynamic. They are not listed in lsf.cluster.cluster_name. Since LSF does not take into account the host name but the number of floating licenses, clients can change dynamically and licenses will be distributed to clients that request to use LSF. When you submit a job from any unlicensed host, and if there are any floating licenses free, the host will check out a license and submit your job to LSF. However, once a host checks out a floating client license, it keeps that license for the rest of the day, until midnight. A host that becomes a floating client behaves like a fixed client all day, then at 12 midnight it releases the license. At that time, the host turns back into a normal, unlicensed host, and the floating client license becomes available to any other host that needs it.

How floating licenses work in LSF

Read this to understand how floating licenses work. You will want to read this before configuring your cluster to use this distribution technique.

When the master LIM starts up, it verifies how many floating licenses there are for the cluster as specified in lsf.cluster.cluster_name with the parameter FLOAT_CLIENTS. The master LIM checks out the licenses and keeps track of license information-how many floating licenses have been assigned, and which client hosts are using the licenses.

Floating client licenses expire at midnight (local time) on the day the license was issued. The master LIM checks the host list and removes any floating client hosts whose license has expired.

License reset

Whenever the master LIM is restarted, all LSF floating client licenses are released and checked out again.

Administration commands

Since LSF floating client hosts are not listed in lsf.cluster.cluster_name, some administration commands will not work if issued from LSF floating client hosts. Always run administration commands from server hosts.

Floating client hosts and host types/models

This differentiates between client hosts and floating client hosts in terms of the restrictions on host types or models.

For LSF client hosts, you can list the host type and model in lsf.cluster.cluster_name and by default, restrict running applications on different host types.

For floating client hosts, host types and models are not included in the client information. By default, any job submissions made from floating client hosts are allowed dispatch to any host type or model.

In the same way as client and server hosts, you can specify a specific model or type when you submit a job from a floating client host.

For example:

bsub sleep 

The command above is interpreted as:

Install LSF floating client licenses

If you believe that the use of floating client licenses is appropriate for your needs, follow this procedure to install LSF floating client licenses.

  1. Obtain the floating client license.
  2. This is similar to getting any other license. See Getting a permanent license.

  3. Update your license file. Add the appropriate license line in the license file license.dat. The LSF license must contain FEATURE lines for LSF_Float_Client.
  4. Although LSF Floating Client requires a license, LSF_Float_Client does not appear in the PRODUCTS line. LSF_Float_Client also cannot be added as a resource for specific hosts already defined in lsf.cluster.cluster_name. Should these lines be present, they are ignored by LSF.

  5. Define server hosts in lsf.conf.
  6. As with any client host, specify the parameter LSF_SERVER_HOSTS in lsf.conf to define LSF server hosts for the LSF client hosts to contact.

  7. Edit lsf.cluster.cluster_name by adding or uncommenting the FLOAT_CLIENTS parameter in the Parameters section:
  8. ... 
    Begin Parameters 
    PRODUCTS=LSF_Base LSF_Manager LSF_Make
    FLOAT_CLIENTS= 25 
    End Parameters 
    ...  
     

    The FLOAT_CLIENTS parameter sets the size of your license pool in the cluster. When the master LIM starts up, the number of licenses specified in FLOAT_CLIENTS (or fewer) can be checked out for use as floating client licenses.

    If the parameter FLOAT_CLIENTS is not specified in lsf.cluster.cluster_name, or there is an error in either license.dat or in lsf.cluster.cluster_name, the floating LSF client license feature is disabled.

  9. Start the license server daemon.
  10. See Start the license daemons.

  11. To allow your changes to take effect, reconfigure the cluster with the commands:
  12. lsadmin reconfig 
    badmin mbdrestart 
     
    caution:  
When the LSF floating client license feature is enabled, any host can submit jobs to the cluster. You can limit which hosts can be LSF floating clients. See Security issues with floating client licenses.

Security issues with floating client licenses

If you want to install or have installed floating client licenses, it is important that you read this section to inform yourself of the security issues. There are measures to compensate for these security issues (see Configuring security for LSF floating client licenses).

With LSF client licenses, when you list client hosts in lsf.cluster.cluster_name, there is a level of security defined since you specify the exact hosts that will be used by the LSF system. Host authentication is done in this way.

With LSF floating client licenses, you should be aware of the security issues:

Configuring security for LSF floating client licenses

Read this section to learn how to configure security against the issues presented in Security issues with floating client licenses.

To resolve these security issues, the LSF administrator can limit which client hosts submit requests in the cluster by adding a domain or a range of domains in lsf.cluster.cluster_name with the parameter FLOAT_CLIENTS_ADDR_RANGE.

FLOAT_CLIENTS_ADDR_RANGE parameter

This optional parameter specifies an IP address or range of addresses of domains from which floating client hosts can submit requests. Multiple ranges can be defined, separated by spaces. The IP address can have either a dotted quad notation (IPv4) or IP Next Generation (IPv6) format. LSF supports both formats; you do not have to map IPv4 addresses to an IPv6 format.

note:  
You must uncomment FLOAT_CLIENTS_ADDR_RANGE (remove the # symbol before the parameter) to have it take effect.

If the value of this parameter is undefined, there is no security and any host can be an LSF floating client.

If a value is defined, security is enabled. When this parameter is defined, client hosts that do not belong to the domain will be denied access. However, if there is an error in the configuration of this variable, by default, no host will be allowed to be an LSF floating client.

If a requesting host belongs to an IP address that falls in the specified range, the host will be accepted to become an LSF floating client.

Address ranges are validated at configuration time so they must conform to the required format. If any address range is not in the correct format, no host will be accepted as an LSF floating client and a error message will be logged in the LIM log.

Conventions
Examples

FLOAT_CLIENTS_ADDR_RANGE=100

All IPv4 and IPv6 hosts with a domain address starting with 100 will be allowed access.

FLOAT_CLIENTS_ADDR_RANGE=100-110.34.1-10.4-56

All client hosts belonging to a domain with an address having the first number between 100 and 110, then 34, then a number between 1 and 10, then, a number between 4 and 56 will be allowed access.
Example: 100.34.9.45, 100.34.1.4, 102.34.3.20, etc. No IPv6 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE=100.172.1.13 100.*.30-54 124.24-*.1.*-34

All client hosts belonging to a domain with the address 100.172.1.13 will be allowed access. All client hosts belonging to domains starting with 100, then any number, then a range of 30 to 54 will be allowed access. All client hosts belonging to domains starting with 124, then from 24 onward, then 1, then from 0 to 34 will be allowed access. No IPv6 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE=12.23.45.*

All client hosts belonging to domains starting with 12.23.45 are allowed. No IPv6 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE=100.*43

The * character can only be used to indicate any value. In this example, an error will be inserted in the LIM log and no hosts will be accepted to become LSF floating clients. No IPv6 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE=100.*43 100.172.1.13

Although one correct address range is specified, because *43 is not correct format, the entire line is considered not valid. An error will be inserted in the LIM log and no hosts will be accepted to become LSF floating clients. No IPv6 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE = 3ffe

All client IPv6 hosts with a domain address starting with 3ffe will be allowed access. No IPv4 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE = 3ffe:fffe::88bb:*

Expands to 3ffe:fffe:0:0:0:0:88bb:*. All IPv6 client hosts belonging to domains starting with 3ffe:fffe::88bb:* are allowed. No IPv4 hosts are allowed.

FLOAT_CLIENTS_ADDR_RANGE = 3ffe-4fff:fffe::88bb:aa-ff 12.23.45.*

All IPv6 client hosts belonging to domains starting with 3ffe up to 4fff, then fffe::88bb, and ending with aa up to ff are allowed. All IPv4 client hosts belonging to domains starting with 12.23.45 are allowed.

FLOAT_CLIENTS_ADDR_RANGE = 3ffe-*:fffe::88bb:*-ff

All IPv6 client hosts belonging to domains starting with 3ffe up to ffff and ending with 0 up to ff are allowed. No IPv4 hosts are allowed.

Checking that security is enabled

Take this step after you have configured security. You are shown how to check that security has been configured properly.

After you configure FLOAT_CLIENTS_ADDR_RANGE, check the master LIM log file on the LSF master host (LSF_LOGDIR/lim.log.master_host_name) to make sure this parameter is correctly set. If this parameter is not set or is wrong, this will be indicated in the log file.

Verify LSF floating client license is working

Perform this procedure after setting up your floating client license to verify that your floating client license is enabled.

  1. Start a cluster.
  2. Run the lshosts command from a host listed in lsf.cluster.cluster_name:
  3. lshosts

    In the following example, only hostA and hostB are defined in lsf.cluster.cluster_name. HostA is a server and master host, and hostB is a static client. If you type the command from hostA or hostB, you will get the following output:

    lshosts 
    HOST_NAME      type    model  cpuf ncpus maxmem maxswp server RESOURCES 
    hostA        SUNSOL  DEFAULT   1.0     1   128M   602M    Yes ()
    hostB        SUNSOL  DEFAULT   1.0     -    -      -       No () 
    
  4. Submit a job from a host not listed in lsf.cluster.cluster_name.
  5. For example, if you submitted the following job from hostC:

    bsub sleep 1000  
     

    You would get the following response:

    Job <104> is submitted to default queue <normal>.
  6. From any LSF host, with LSF_ENVDIR set to this cluster, run the lshosts command:
  7. lshosts 
    HOST_NAME type     model    cpuf ncpus maxmem maxswp server    RESOURCES  
    hostA     SUNSOL   DEFAULT   1.0   1   128M   602M    Yes       ()  
    hostB     SUNSOL   DEFAULT   1.0   -      -      -     No       ()  
    hostC     UNKNOWN  UNKNOWN   1.0   -      -      -     No       ()   
     

    In the above example, although hostC shows the type UNKNOWN and hostA and hostB are of type SUNSOL (Sun Solaris), the job will be allowed to be executed on any host type because hostC is a floating client host without any model or type restrictions specified at job submission.

  8. From any host, run the lshosts -l command:
  9. lshosts -l hostC 
     

    where hostC is a floating client host.

    HOST_NAME: hostC type        model    cpuf ncpus ndisks maxmem maxswp maxtmp rexpri server UNKNOWN    UNKNOWN   1.0 - - - - - - No RESOURCES: Not defined RUN_WINDOWS: Not applicable for client-only host LICENSES_ENABLED: (LSF_Float_Client)

Troubleshooting License Issues

"lsadmin reconfig" gives "User permission denied" message

If you ran lsfinstall as a non-root user to install a multi-user cluster, the LSF administration commands lsadmin and badmin might give the error message "User permission denied".

Use the following commands to change the ownership for lsadmin and badmin to root and the file permission mode to -rwsr-xr-x:

chown root lsadmin badmin 
chmod 4755 lsadmin badmin 

Now the user ID bit for the owner is setuid. If lsadmin and badmin are in a directory shared through NFS, the directory must be shared and mounted with setuid enabled. Do not mount with the nosuid flag. If your site does not permit this, copy lsadmin and badmin to /usr/bin or /bin.

Primary cluster administrator receives email "Your cluster has experienced license overuse" message

This occurs when your cluster is using more licenses than you have purchased. LSF allows for some overuse due to the peak usage of the cluster.

See the lsf.cluster_name.license.acct file for details of the peak license usage of your cluster:

OK

Peak usage is less than the maximum license availability

OVERUSE

Peak usage is more than the maximum license availability

If your cluster experiences frequent license violations or overuse, contact Platform Computing or your Platform LSF vendor to get more licenses, or plan your cluster to reduce the license usage during peak periods.

lsadmin command fails with "ls_gethostinfo: Host does not have a software license"

This may occur when you have installed the new key but have an old (unlicensed) LIM running on the LSF master.

  1. On the LSF master, enter the command:
  2. ps -ef | grep lim

  3. Kill the LIM, using one of the following commands:
  4. kill lim_PID 
    kill -9 lim_PID 
    
  5. After the old LIM has died, start the new LIM on the master host using one of the following methods:

LSF commands give "Host does not have a software license"

You may see this message after running lsid, lshosts, or other ls* commands.

Typical problems: and their solutions:

If you experience this problem ...
Do the following:
Your demo license (not tied to FLEXlm server) has expired.
Check the license.dat file to check the expiry date.
If your license has expired, contact your account manager to obtain a new demo key or a permanent license.
Your license file may have incorrect formatting. One of the following things may be responsible:
The license file was edited in Windows and incorrect line ending characters (^M) exist in the file.
The license file may have more than one FEATURE on a line.
You should have a line break at the end of each FEATURE line. Remove the excess ^M characters or line breaks from the license file.
If the license key is tied to a FLEXlm server, restart lmgrd.
Restart the master LIM.
The LSF master host is unable to communicate with the FLEXlm server.
Check the network communication by entering the command:
ping FLEXlm_server 
License daemons (lmgrd and lsf_ld) are not running on the FLEXlm server.
Check if lmgrd and lsf_ld are running by typing:
ps -ef | egrep 'lmgrd|lsf_ld'  
on the FLEXlm server. If not:
Check the license.log file for error messages.
Start lmgrd.
Restart the master LIM.

LSF commands fail with "ls_initdebug: Unable to open file lsf.conf"

You might see this message after running lsid. This message indicates that the LSF commands cannot access the lsf.conf file or lsf.conf does not exist in LSF_ENVDIR.

Solution:

lmgrd fails with message "Port already in use"

The port number defined in LSF_LICENSE_FILE and license.dat is being used by another application (by default, LSF uses port number 1700).

Possible causes:

If you experience this problem ...
Do the following:
lmgrd is already running for this license
Use ps -ef and make sure that lmgrd and lsf_ld are not running.
lmgrd has been stopped and the operating system has not cleared the port
Wait a few minutes for the OS to clear this port.
Another process is using the same port (this is not likely)
If the port number is being used by another application, execute the following to change the port number used by LSF:
  1. Edit license.dat and change the port number in the line:
SERVER flexlm_server 3f8b6a3 1700
  • The fourth field on the SERVER line of license.dat specifies the TCP port number that the FLEXlm server uses. Choose an unused port number. The default port set by FLEXlm is 1700. Platform LSF usually uses port numbers in the range 3879 to 3882, so the numbers from 3883 forward are good alternate choices.
  • In lsf.conf:
    • If LSF_LICENSE_FILE is defined as follows: LSF_LICENSE_FILE=port_number@flexlm_server (for example: 1700@hostA), the port number must be changed accordingly.
    • If LSF_LICENSE_FILE points to the license file path (for example: LSF_LICENSE_FILE=/usr/local/lsf/conf/license.dat), no changes are required.
    • Restart lmgrd.


Platform Computing Inc.
www.platform.com
Knowledge Center         Contents    Previous  Next    Index