PGI User Forum
 SearchSearch   MemberlistMemberlist     RegisterRegister   ProfileProfile    Log inLog in 

CUDA-x86.

Weird license failure

 
Post new topic   Reply to topic    PGI User Forum Forum Index -> Licenses and Installation
View previous topic :: View next topic  
Author Message
gap



Joined: 17 May 2007
Posts: 14

PostPosted: Fri May 06, 2011 10:30 am    Post subject: Weird license failure Reply with quote

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:

***************

pgi-f95-lin64: LICENSE MANAGER PROBLEM:
Feature: pgi-f95-lin64
License path:
51000@yell-lice.lanl.gov:51012@null.lanl.gov:/scratch3/XXX/PGI_rr-dev/pgi_9.0-3/license.dat:

***************

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?
Back to top
View user's profile
jtull



Joined: 30 Jun 2004
Posts: 373

PostPosted: Fri May 06, 2011 5:10 pm    Post subject: Reply with quote

gap,

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.

regards,
dave
Back to top
View user's profile
gap



Joined: 17 May 2007
Posts: 14

PostPosted: Mon May 09, 2011 8:43 am    Post subject: Reply with quote

jtull wrote:
gap,

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.


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.

jtull wrote:
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.

regards,
dave



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 ;-)
Back to top
View user's profile
jtull



Joined: 30 Jun 2004
Posts: 373

PostPosted: Mon May 09, 2011 3:49 pm    Post subject: Reply with quote

gap,

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

-dryrun

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.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    PGI User Forum Forum Index -> Licenses and Installation All times are GMT - 7 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © phpBB Group