Weird license failure

We run a floating license for multiple high performance compute clusters. (Actually, we run 3 floating licenses, each of them serving non-overlapping sets of HPC clusters. That’s relevant.)
Yesterday, I had a user reporting this error intermittently:

Feature: pgi-f95-lin64
License path:

Port 51012@null is a valid license variable for PGI.

Port 51000@yell-lice is a different product - it’s not even a compiler, just happens that both products use “LM_LICENSE_FILE” as their preferred environment variable.

The file specified as residing in /scratch3 does not exist, and the /scratch3/XXX space doesn’t even belong to the user who reported the error. We’ve checked through the user’s environment and relevant makefiles, and we don’t see this reference anywhere.

This morning we have a new twist - same user, same intermittent error, SAME REFERENCE to the scratch3 filename, this time from a compute cluster that uses a completely different license server.

We have NO IDEA how PGI is carrying around a bogus license definition, much less wandering around in the scratchspace of a different user to look for it. Do you?


This License Path behavior is a mystery to us. Perhaps .bashrc or .cshrc file
where this license path is getting set. We have no idea where
that path is being set.

Note that if more than one of the floating licenses being
served by the same license server are PGI licenses, there
may be problems. The PGI licenses do overlap in the product
strings covered, and as a result, you may only be getting use
out of one of the PGI licenses. Once lmgrd finds the product
strings in a license file, it stops looking - effectively only one
PGI license is being used. So even if you have separate
clusters being served by a common license server, you better not
be using two PGI licenses - they will need two servers. I just
wanted to remove any confusion on this topic.


We use the open source “Modules” package to set user environment variables such as those needed for PGI. So we know where the correct definition is coming from :-) We had the user check his dotfiles, and he claims not to have found any conflicting LM_LICENSE_FILE definitions; output of “env | grep LICENSE” seems to confirm. The fact that the same user has the same problem - in two physically separated environments - makes us very suspicious that it is buried in his environment somewhere; we just haven’t found it yet, and wondered if y’all had any other suggestions.
Thanks. We’ll chalk this up to unreproducible.

Yes, we are aware of this. Just to clarify - each of our PGI licenses is only running on one server, each serving a discrete set of compute clusters. And on these separate servers, each of our licensed products is running under its own “lmgrd” process, we don’t combine product licenses either. So there’s no possible confusion at our end - just at the user level ;-)


Sorry about the pedantic response. We have every level of ability among users
regarding the license mechanism, and you appear to be at least as competent as me.

I have looked everywhere trying to find this pathname addition. I cannot.
Perhaps if you run the compilers with the


switch, yuo can see all the rc files that PGI and users create to control the
action of the compilers.

I suggest you find a system where your phantom license path is not part
of the $LM_LICENSE_FILE path, and see if using the compilers causes it to
be added again. Or remove it and see if it returns with compiler usage.