This article is targeted for specific use cases, where we have the license server and client connectivity issues (not a delay, but failure). This best practice guide is to be followed to make sure that all the official/minimal checks and setup are in place. 1.) Ensure that the Server and Client can perform a basic 'ping' to each other. 2.) If possible, try including an entry in /etc/hosts file for both against each other - respectively. 3.) It is recommended to bind the SERVER and vendor daemon to a specific TCP port (not mandatory), as: SERVER <host_name> <HOSTID> 27000 VENDOR demo PORT=56789 4.) On server & Client, add both of these ports under the allowed list for 'to ' and 'from' list for internal and external network communication. This should be done for OS firewall as well as any antivirus software if in place. 5.) Add the lmgrd, vendor daemon executable, and client application executable (it could be normal lmflex OR TS-based utilities such as appactutil, serveractutil OR lmstat, lmutil) into the exception list for Antivirus, if the option is available. 6.) Look into the Power settings and select the option for "sleep" as Never - so that non of the USB (if dongle in use), Hardware, Kernel or I/O operations are put under hold in case of inactivity for a long time - which is common on server systems. 7.) On some operating systems (Flavors of windows), there should be an option for "hardware Sleep" settings (Under Edit Plan Setting > Change Advanced Power Setting) - please select that as Never. NOTE: A license server should never be put in a sleep mode, as even when there is no client activity on the server, internally there will be a heartbeat mechanism being followed in-between "lmgrd<->vendor daemon" & "client <->vendor daemon" - to ensure that server & Vd are up and still serving the licenses. For systems that get under sleep for more than the default (automatic) heartbeat threshold for vendor daemon & lmgrd communication cycle delay i.e. 300 seconds, on revival license server may get shutdown/restart with an error and subsequent statement in debug log as:          HH:MM:SS (VD_name) Lost connection to lmgrd, heartbeat timeout expired, exiting.          HH:MM:SS (VD_name) Heartbeat timeout is 300 seconds. Elapsed time is XXXXXXX seconds.          HH:MM:SS (VD_name) EXITING DUE TO SIGNAL 28 Exit reason 5 It can be avoided by either making changes in Step-6 & 7. OR,  8.) For scenarios of latency: Windows Only Solution: To use environment variable "FLEXLM_TIMEOUT": Sets the timeout value a FlexEnabled application uses when attempting to connect to a license server. Values are in microseconds, within the range of 200,000 (0.2 seconds) through 20,000,000 (20 seconds). The default value is 3,000,000 microseconds (that is 3 seconds).   For a more Universal Approach: Try using the client attribute 'LM_A_CONN_TIMEOUT'. LM_A_CONN_TIMEOUT attribute defines the maximum time (in seconds) the client would wait to receive a response after sending a single request to the license server. This attribute allows publishers to change the default timeout value if needed.   Note • The timeout should not be increased too much from its default value as this will affect client performance in bad network conditions, and in such scenarios, the publisher may wish to perform some experiments to determine a suitable timeout value. The trade-off is small values results in better client performance but large values result in a decreased probability of clients being timed out. 9.) To improve the further performance, kindly have a look at below KB articles as well: https://community.flexera.com/t5/FlexNet-Publisher-Knowledge-Base/IPv4-and-IPv6-address-prioritization-for-licensing-communication/ta-p/130022 10.) If the above steps don't help, then please log a case with support@revenera.com.  ... View more

Starting FNP-11.17.2 release, the debug log statement in the options file now comes with the possibility of automatic rollover of debug log files if a pre-defined condition is met (size of debug log file). The "AUTO_ROLLOVER" option with DEBUGLOG keyword enables the auto rollover of debug log file, which automatically performs the rollover functionality of debug log file when the debug log file size reaches the specified value. Syntax: DEBUGLOG [+]debug_log_path [OBF_ADDMARK] [AUTO_ROLLOVER size] Here the last entry about [AUTO_ROLLOVER] is the enhancement related to the rollover of debug log. The AUTO_ROLLOVER option enables the auto rollover of debug log file, which automatically performs the rollover functionality of debug log file when the debug log file size crosses the specified value. The default value would be 512MB. The automatic rollover will always be performed at midnight. Here is the bare minimum step to perform the setup in motion: 1.) Create an option file as below to enable AUTO_ROLLOVER DEBUGLOG +debug.log AUTO_ROLLOVER 5KB Note : Here we can specify KB/MB/GB for file size to rollover 2.) Start the License server closer to midnight, for testing purpose (or change the system date in Test Environment ONLY). 3.) In the debug log, a set of logs will confirm that AUTO_ROLLOVER settings have been picked up by the license server, on startup. 23:58:54 (panda) Debug log started (+debug.log). 23:58:54 (panda) OBF_ADDMARK is disabled 23:58:54 (panda) DEBUGLOG AUTO_ROLLOVER is enabled with rollover size of 5120 bytes 23:58:54 (lmgrd) panda using TCP-port 59848 4.) When approaching midnight, ensure that the existing debug log has crossed the 5KB size threshold, if not then perform a series of checkout-checkin cycles / Manual reread. 5.) Post the midnight reread, auto rollover should happen and debug.log contents should have moved out to the newly generated file [<vendor daemon name><hostname><date> T<time>.log]. 6.)  debog.log should have successful Rollover details. 0:14:49 (panda) Successful roll-over of debug log file debog.log. The debug log back-up is available in panda_BLR-LT-101128_02-17-2021_T00056.log 7.)  panda_BLR-LT-101128_02-17-2021_T00056.log should have all the data of debog.log before rollover. The similar code flow to automatic rollover of debug log will be performed based on its current size on every midnight server reread.   ... View more

For v11.17.0: New vendor variable ls_diagnostics_enabled, enabled by default. Message-based diagnostics is emitted only by POSIX license servers (Linux, Solaris, macOS, HP-UX and AIX). Whilst diagnostics will be generated from messages sent by legacy clients, these clients will not send session information. The Java client has limited diagnostics support - it will not send the SessionID or ProcessID Message-based diagnostics has limited support from lmadmin, specifically, heartbeat messages cannot be identified as coming from the lmadmin. From v11.18.0: Diagnostics port listener is supported on Windows 10 from build 17093 and not supported on Windows 7 and Windows 10 earlier than build 17093. Steps to Perform:  Build the default FNP toolkit for your native vendor daemon. Start the license server with a crypted license file. For demo, we will use ‘log2file’ executable to log the diagnostic messages for server-client communication.                   Make sure that ‘log2file’ executable is built post toolkit build. If not then take a reference from v11.18.0 makefile and build the executable by                         running “nmake log2file.exe” Start the diagnostic Deamon logging by running the command (in a separate command prompt), as:                     “log2file.exe lmgrd_diag.csv”   Perform the checkout and checkin operation through few client calls (lmflex). Perform the lmstat on active server. Now, bring the server down. Post that, navigate to the created excel sheet names ‘lmgrd_diag.csv’. It should have entries against client communication, as:     This file logs the parallel client operation names under Component. Be advised about other options as “log2db.exe” & “log2port.exe”. Kindly refer to documentation for more details about these executables. Diagnostics Filtering Filtering can occur pre- or post-message-based diagnostics is persisted. The former kind of filtering might typically occur in order to save disk space, whereas the latter would typically occur when searching for the source of capacity overload in the server. An example of pre-persistence filtering is available in the log2db.c sample. The command line...  ./log2db -i -d diag.db COMPONENT=^lc_check ... will only write records (aka diagnostic message rows) to the database that match the COMPONENT=^lc_check regular expression - that is, only rows corresponding to messages generated from lc_checkout or lc_checkin API calls. Filtering can occur on any field or on any combination of fields.  API based message diagnostics customization: A single row of diagnostics data corresponds to one message sent to the license server. However, many client API calls, such as lc_checkout, comprise several messages. In order to be able to trace all the messages from a particular lc_* call instance, FNP clients now have the concept of a session - each diagnostics row has a SessionID. By default, a session exists for the duration of any one lc_* call. However, it may be that producers want to define a session as encompassing multiple lc_* calls. For this purpose two new APIs are provided lc_diagnostics_start(unsigned int   value); // max 28-bits value lc_diagnostics_end(); These optional APIs are intended to wrap a section of code in a lmflex client that a producer wishes to identify as a session. The   value   will be reported as Component= USER and Info=hex(value) in diagnostics. The SessionID used for all messaged wrapped by lc_diagnostics_start/end will be constant and based on the   value. Message-based diagnostics are in addition to and separate from the diagnostics already being written to the server log. Example of Implementation: Client Implementation: User-defined Info and SessionID lc_diagnostics_start(10); lc_checkout(lm_job, FEATURE, "1.0", 1, LM_CO_NOWAIT, &code, LM_DUP_NONE)); lc_checkin(lm_job, FEATURE, 0); lc_diagnostics_end();         ... View more

>> Big Sur the next major version of macOS is the first version to support Macs with ARM-based processors in addition to Intel. FlexNet Publisher(FNP) product's response to this, is to deliver a Universal 2 kit for FNP(That has both Native ARM + Intel support) by Mid-2021. Meanwhile,  Big Sur Intel: We carried out a full cycle test of existing kits of FNP x64_mac10 (11.18.0). The testing was smooth on Big Sur Intel. So customers can use existing kits on Big Sur Intel until we deliver universal 2 kits. Big Sur ARM(Rosetta 2 / Emulated): About using the existing kits(x64_mac10-11.18.0) in emulated/Rosetta 2 mode on Big Sur ARM. We believe FNP interacts with many low-level system APIs which don't go well with emulation. We did some sanity/smoke tests in emulated/Rosetta mode and the outcome was that the tests passed successfully. We also have feedback from some of our customers, that their software using FNP Licensing ran smoothly in Rosetta 2 mode on Big Sur ARM. We understand that your eventual end customers are going to attempt running your software and hence FNP too in Rosetta 2 mode. This can be a stopgap solution for your temporary needs but we are unable to commit resources to perform full regression tests and support in emulated mode. Our direction is towards native support for ARM and will be delivered via the Universal 2 kits. ... View more