Linux & Bash · Part II · Module 25 · EDA Environment and Tool Access

Licence Environment and Diagnosing Licence Failures

A licence failure is the most common reason a correctly installed tool refuses to run, and the most commonly misdiagnosed — because 'no licence available' and 'no licence for this feature' and 'cannot reach the server' are three different problems that people treat as one. This chapter separates them by what the log says.

Intermediate21 min readLinuxPart IILicencesEDADiagnosis

Part II · Module 25 · Chapter 25.4 · Licence Environment and Diagnosing Licence Failures

No real licence manager is installed here — lmstat and lmutil are both absent, as Chapter 25.1 §1 verified. So the diagnosis is demonstrated with a stand-in that reads the same file format and fails in the same four ways. Vendor-specific output is described rather than shown.

1. What a Licence Source Actually Is

The variable does not hold a path. It holds a colon-separated search list, and each element is either a file or a port@host:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ echo '27000@licsrv1:/proj/lic/site.lic:27000@licsrv2' | tr ':' '\n' | nl
     1	27000@licsrv1
     2	/proj/lic/site.lic
     3	27000@licsrv2

Three sources, tried in order, and the first one that grants the feature wins. That has two consequences people trip over:

A broken first entry costs time, not correctness. A dead server at position one means every tool launch waits for a timeout before trying position two. The tool eventually works and everything is slow, which is diagnosed as "the network" far more often than as "the licence list".

And adding a source does not remove one. Appending your own file to the front does not stop the site servers being consulted for features yours does not grant — which is usually what you want, and occasionally the reason a tool picks up an unexpected feature version.

Parsing it is the first thing a diagnostic should do:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ src=27000@licsrv1:/proj/lic/site.lic:27000@licsrv2
$ IFS=: read -r -a parts <<< "$src"
$ for p in "${parts[@]}"; do
>   case $p in
>     (*@*) printf '  server  %s (port %s host %s)\n' "$p" "${p%%@*}" "${p#*@}" ;;
>     (*)   printf '  file    %s\n' "$p" ;;
>   esac
> done
  server  27000@licsrv1 (port 27000 host licsrv1)
  file    /proj/lic/site.lic
  server  27000@licsrv2 (port 27000 host licsrv2)

IFS=: read -r -a splits on colons into an array, with IFS set for one command so it cannot leak — Chapter 9.2 §6. ${p%%@*} and ${p#*@} take the port and the host with no cut processes — Chapter 8.3. And the case patterns are parenthesised, for the Bash 3.2 reason Chapter 25.1's callout measured.

Which variable, and why there are so many

There is no single licence variable. Three layers of naming exist, and a site typically uses all three:

Variable	Scope
`LM_LICENSE_FILE`	every FlexLM-based tool on the machine
`<VENDOR>_LICENSE_FILE` — `SNPSLMD_LICENSE_FILE`, `CDS_LIC_FILE`, `MGLS_LICENSE_FILE`	one vendor's tools
A tool-specific variable	one tool

The vendor-specific one usually takes precedence, and using it is better practice than the global one, because LM_LICENSE_FILE makes every tool on the machine consult every server — which is the main cause of slow launches at sites with many vendors.

Finding which one your tool reads is a question for its documentation, and the measurable half is which ones are set:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

env | grep -iE 'licen[sc]e|_LIC_|LM_' | sort

licen[sc]e because the spelling is inconsistent across vendors — LICENSE in most, LIC in others — and -i because case is not reliable either. An empty result on a machine where tools work means they are finding licences some other way, which is worth knowing about.

2. A Licence File, Read as Data

A licence file is text, and the two lines that matter are legible:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ cat licenses/site.lic
SERVER licsrv1 ANY 27000
FEATURE simtool 2024.0901 31-dec-2026 8 SIGN=A1B2
FEATURE simtool_vip 2024.0901 31-dec-2026 2 SIGN=C3D4
FEATURE othertool 3.2 01-jan-2026 4 SIGN=E5F6

SERVER names where the daemon runs. Each FEATURE line is what is licensed, which version, until when, and how many seats. So three questions are answerable with awk and no vendor tool at all:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ awk '/^FEATURE/ {print $2}' licenses/site.lic
simtool
simtool_vip
othertool
$ awk '$1=="FEATURE" && $2=="simtool" {print "seats: "$5"  expires: "$4}' licenses/site.lic
seats: 8  expires: 31-dec-2026

Eight seats and an expiry in 2026. That is the difference between "we have no licence for this" and "all eight are in use right now", which are the two most commonly confused licence problems and have completely different remedies.

Chapter 13.7's field model is all this needs. Note $1=="FEATURE" rather than /^FEATURE/ in the second one: a field comparison cannot match the word appearing inside a comment, which a regex can.

3. Four Failures, Four Statuses

The stand-in lmstat reads the file and fails the four ways a real one does.

It works:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ SIMTOOL_LICENSE_FILE=$PWD/licenses/site.lic ./tools/bin/lmstat
License server status: 27000@licsrv1
FEATURE          TOTAL  USED  EXPIRES
simtool              8     2  31-dec-2026
simtool_vip          2     0  31-dec-2026
othertool            4     1  01-jan-2026
$ echo $?
0

No source set:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ./tools/bin/lmstat
lmstat: no licence source set (SIMTOOL_LICENSE_FILE)
$ echo $?
2

The source names a server it cannot reach:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ SIMTOOL_LICENSE_FILE=27000@licsrv1 ./tools/bin/lmstat
lmstat: cannot contact license server 27000@licsrv1
$ echo $?
3

The source names a file it cannot read:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ SIMTOOL_LICENSE_FILE=/nope.lic ./tools/bin/lmstat
lmstat: cannot read /nope.lic
$ echo $?
2

And from Chapter 25.1 §4, the tool distinguishes three of its own: 3 for an unset variable, 4 for an unreadable file, 5 for a file that grants no feature for it.

Together that is the whole decision tree, and it is worth having in your head because the messages in real tools are longer and less clear:

Symptom	Means	Fix
"variable not set"	the environment was never set up	source the setup script
"cannot read file"	the path is wrong, or not visible from this machine	check the path, and `df` it
"cannot contact port@host"	network, firewall, or the daemon is down	ask; you cannot fix it
"no feature for this tool"	the licence is real and does not cover this tool	ask for the feature
"all licenses in use"	the licence covers it and the seats are taken	wait, or queue
the tool starts and the design fails	not a licence problem	read the log

The last row is the one this chapter exists for.

4. Telling a Licence Failure From a Tool or Design Failure

Three failures that look alike, and the one observation that separates each

The top row is what you are trying to tell apart; the bottom row is the single thing to look at. A licence failure stops before the design is read, so the log has nothing about the design in it; a tool failure produces a tool-shaped error and a non-zero status; and a design failure produces a full log and frequently exits zero. One glance at the log's length and content decides between all three.

Three failures that look alike from a distance, separated by one observation each:

A licence failure happens before the tool reads your design. So the log has no compile output, no elaboration, no time-zero messages — it stops at the banner. If your log contains anything about your design, the licence was granted.

A tool failure produces a tool-shaped error and usually a non-zero status, as Chapter 22.2 §3 measured for a syntax error.

A design failure produces a full log and — measured in that same chapter — frequently exit status 0. A run that produced forty thousand lines and exited 0 did not have a licence problem, whatever its last line says.

The mid-run licence loss, which breaks that rule

There is one case where a licence failure appears in the middle of a full log, and it is the nastiest failure in this chapter: a long run checks its licence out at the start, holds it, and loses it part way through — because the server was restarted, the network blipped, or a higher-priority user pre-empted the seat.

The signature is a log that looks healthy for thousands of lines and then stops, with a licence message at the end rather than the beginning:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

… 40,000 lines of simulation …
UVM_INFO @ 1823000: … [AXI_MON] addr=0x0000f9f0 …
FLEXnet Licensing error: lost connection to license server

Three things follow from this, and all three are reasons to care:

It is indistinguishable from a crash by status alone. The tool dies, often on a signal, so the status is 128 + N — Chapter 25.3 §2's arithmetic again.

Re-running usually works, which is why it gets dismissed as "flaky" and never investigated.

And it is detected by looking at the END of the log, not the beginning:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

tail -20 "$log" | grep -iE 'licen[sc]e|flexnet|flexlm|lmgrd'

That one line belongs in every regression triage script, because a run lost to a licence is not a design failure and must not be counted as one. Chapter 33.1 is where triage gets its own chapter — measuring three different causes that produce byte-identical logs; Chapter 34.3 is where a flow learns to retry this class of failure and not others.

5. The Diagnostic Script

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

#!/usr/bin/env bash
# licheck — is the licence environment usable, and what does it grant?
#
# usage: licheck [-v VARNAME] [feature]
#   -v  the variable holding the licence source (default: LM_LICENSE_FILE)
# exit: 0 usable · 1 a problem was found · 2 usage
set -o nounset

var=LM_LICENSE_FILE
while getopts ':v:' o; do
  case $o in
    (v) var=$OPTARG ;;
    (:) printf 'licheck: -v needs a variable name\n' >&2; exit 2 ;;
    (\?) printf 'licheck: unknown option -%s\n' "$OPTARG" >&2; exit 2 ;;
  esac
done
shift $(( OPTIND - 1 ))
feature=${1:-}
bad=0

printf -- '-- licence variables that are set\n'
set_any=0
while IFS= read -r line; do
  printf '   %s\n' "$line"; set_any=1
done < <(env | grep -iE 'licen[sc]e|_LIC_FILE|^LM_' | sort)
[ "$set_any" -eq 1 ] || { printf '   (none)\n'; bad=1; }

eval "src=\${$var:-}"
printf -- '\n-- %s\n' "$var"
if [ -z "${src:-}" ]; then
  printf '   NOT SET\n'; bad=1
else
  IFS=: read -r -a parts <<< "$src"
  for p in "${parts[@]}"; do
    case $p in
      (*@*)
        printf '   server  %-24s port %-6s host %s\n' "$p" "${p%%@*}" "${p#*@}"
        printf '           (reachability not tested from here)\n' ;;
      ('')
        printf '   ** an empty element — a stray colon in %s\n' "$var"; bad=1 ;;
      (*)
        if [ -r "$p" ]; then
          printf '   file    %s\n' "$p"
          n=$(awk '$1=="FEATURE"' "$p" | grep -c . || true)
          printf '           %s feature line(s)\n' "$n"
          if [ -n "$feature" ]; then
            awk -v f="$feature" '$1=="FEATURE" && $2==f {
                printf "           GRANTS %s  version %s  expires %s  seats %s\n", $2,$3,$4,$5; found=1 }
              END { if (!found) printf "           does NOT grant %s\n", f }' "$p"
            awk -v f="$feature" '$1=="FEATURE" && $2==f {found=1} END {exit !found}' "$p" || bad=1
          fi
        else
          printf '   ** cannot read %s\n' "$p"; bad=1
        fi ;;
    esac
  done
fi

[ "$bad" -eq 0 ]

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ SIMTOOL_LICENSE_FILE=$PWD/licenses/site.lic licheck -v SIMTOOL_LICENSE_FILE simtool
-- licence variables that are set
   SIMTOOL_LICENSE_FILE=/home/engineer/eda/licenses/site.lic

-- SIMTOOL_LICENSE_FILE
   file    /home/engineer/eda/licenses/site.lic
           3 feature line(s)
           GRANTS simtool  version 2024.0901  expires 31-dec-2026  seats 8
$ echo $?
0

Six decisions:

An empty element is reported. a::b in a licence source is a stray colon, and it is a real and confusing bug — some tools treat an empty element as the current directory. A diagnostic that silently skipped it would hide the cause.

Server reachability is declared untested, not guessed. Testing it needs a TCP connection to a vendor daemon, and claiming otherwise would be the false green Chapter 25.1's callout was about.

The feature check runs awk twice — once to print, once for the status. That is deliberate: an awk that both prints and sets an exit code is harder to read than two passes over a file that is a few hundred lines long, and Chapter 13.7 §6's one-pass argument is about large inputs, not small ones.

$1=="FEATURE" rather than /^FEATURE/, so the word inside a comment cannot match.

eval "src=\${$var:-}" to read a variable named by a variable, with the same caveat as Chapter 25.1 §6: Bash 3.2 has ${!var} but not a clean ${!var:-}, and the name comes from the user.

And every case pattern is parenthesised, because this case sits inside a for inside a script that also uses < <( ) — and once one case in a file needs the form, using it everywhere is less surprising than using it in one place.

awk's exit runs the END block, and END's exit wins — measured

The status check in that script was written the obvious way first, and it was wrong:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

awk -v f="$feature" '$1=="FEATURE" && $2==f {exit 0} END {exit 1}' "$p"

Read as C or shell, that says "if you find the feature, exit 0; otherwise exit 1". Run against a file that does grant the feature:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ awk '$1=="FEATURE" && $2=="simtool" {exit 0} END {exit 1}' licenses/site.lic
$ echo $?
1

One, on a licence that grants simtool. So licheck reported a perfectly good environment as broken, and the rest of its output said the opposite — a diagnostic contradicting itself.

The cause is a rule in POSIX awk that catches everyone once: exit does not exit. It transfers control to the END block, which then runs — and whatever END exits with replaces your status.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ awk 'NR==1 {print "  matched on line 1"; exit 0} END {print "  END ran!"; exit 1}' licenses/site.lic
  matched on line 1
  END ran!
$ echo $?
1

Both lines print. And with no exit in END, the earlier status does stand:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ awk 'NR==1 {exit 0} END {print "  END saw it"}' licenses/site.lic
  END saw it
$ echo $?
0

So there are two correct spellings, both measured:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ awk -v f=simtool '$1=="FEATURE" && $2==f {found=1} END {exit !found}' licenses/site.lic ; echo $?
0
$ awk -v f=nope    '$1=="FEATURE" && $2==f {found=1} END {exit !found}' licenses/site.lic ; echo $?
1

Set a flag in the body and exit only in END — which is what the script now does — or avoid the question entirely by letting grep own the status:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ awk '$1=="FEATURE" {print $2}' licenses/site.lic | grep -qx simtool ; echo $?
0

exit !found is worth reading carefully: found is empty (false) or 1, ! inverts it, so the status is 1 when nothing was found and 0 when something was. That is the opposite convention from the body of the program and the right one for a shell caller — Chapter 11.1's zero-is-success, which awk's own ! happens to produce for free.

The reason this earns a callout rather than a footnote: the failure was a false red — the inverse of the false green in Chapter 25.1. A diagnostic that reports a healthy system as broken gets switched off just as fast as one that reports a broken system as healthy, and it was caught only by running the script against an environment known to be good. Chapter 21.8 §4 insists on breaking the subject to see the check fail; this is the other half of the same discipline — run it on something that should pass.

Practice

Run env | grep -iE 'licen[sc]e|_LIC_|LM_' on a machine with tools installed. How many variables, and do any disagree?
Split your licence source on colons and classify each element as a file or a server.
For each file element, check it is readable from a compute node, not just from your workstation.
Count the FEATURE lines in a licence file you can read. Which features does it grant?
Find the seat count and expiry for a feature you use.
Put a deliberately dead port@host at the front of your licence source and time a tool launch. How much slower?
Add a stray double colon and see what your tool does.
Find a log from a licence failure. Does it contain anything about your design?
Find a log where the tool ran and the test failed. What was the exit status?
Write the tail -20 | grep -i licence check and run it over a directory of old logs. Any hits?
Write licheck and run it with a correct environment, then with the variable unset, then pointing at an unreadable file.
Ask it about a feature the licence does not grant and confirm exit 1.

Check Your Understanding

What does a licence variable actually contain?
What are the two consequences of it being an ordered list?
Why is a vendor-specific variable better practice than LM_LICENSE_FILE?
What four things does a FEATURE line tell you?
Why $1=="FEATURE" rather than /^FEATURE/?
What are the two licence problems people most often confuse?
How do you tell a licence failure from a design failure by looking at the log?
What is the one case where a licence message appears at the end of a full log?
Why is that case usually dismissed as flaky?
Why does licheck say server reachability is untested?
Why is an empty element in a licence source worth reporting?

Answers

1. A colon-separated search list, where each element is either a licence file or a port@host server — not a single path. 2. A broken first entry makes every launch wait for a timeout before trying the next, so the symptom is slowness rather than failure; and adding a source does not remove the others, so features may still come from elsewhere. 3. Because LM_LICENSE_FILE makes every FlexLM tool on the machine consult every server listed, which is the main cause of slow launches at multi-vendor sites. 4. What feature is licensed, which version, until when, and how many seats. 5. Because a field comparison cannot match the word appearing inside a comment, which a line-anchored regex can. 6. "There is no licence for this tool" and "all the seats are currently in use" — different causes and completely different remedies. 7. A licence failure happens before the tool reads the design, so the log stops at the banner with nothing about your design in it. If the log contains elaboration or simulation output, the licence was granted. 8. A mid-run licence loss: the tool holds a seat for a long run and loses it when the server restarts, the network blips, or it is pre-empted. 9. Because re-running usually works, so it is attributed to flakiness instead of being counted as an infrastructure failure. 10. Because testing it requires a TCP connection to a vendor daemon; claiming to have checked would be a false green. 11. Because a::b is a stray colon that some tools interpret as the current directory, which is a real and very confusing source of wrong-licence behaviour.

6. Remember

A licence variable is a colon-separated search list, each element a file or a port@host.
It is ordered: a dead first entry makes launches slow, not failed.
Prefer the vendor-specific variable to LM_LICENSE_FILE, which makes every tool ask every server.
A FEATURE line gives the feature, version, expiry and seat count — all readable with awk.
"No licence for this tool" and "all seats in use" are different problems. The seat count tells you which.
Use $1=="FEATURE", not a line-anchored regex.
Measured: four failures, four statuses — unset (2), unreadable file (2), unreachable server (3) from the status tool; and 3, 4, 5 from the tool itself for unset, unreadable and no-feature.
A licence failure stops the log at the banner. Anything about your design means the licence was granted.
A design failure often exits 0 with a full log — not a licence problem.
A mid-run licence loss is the exception: a healthy log that stops, with the licence message at the end. Check tail -20 | grep -i licen.
Report an empty element in the source — a stray colon is a real bug.
Do not claim to have tested a server you did not contact.
awk's exit runs the END block, and END's exit replaces your status. Set a flag and exit !found in END, or let grep -qx own the status.
Run a diagnostic against a known-good environment too. A false red gets switched off as fast as a false green.
Parenthesise case patterns in anything that also uses $( ) or < <( ) under Bash 3.2.

7. What Is Next

Chapter 25.5 moves from the tool's own variables to the project's: the small agreed set that stops scripts containing absolute paths which resolve on exactly one person's machine.

Where this fits

Part of the Linux & Bash curriculum.