Project

General

Profile

Bug #2814

Condor 7.7.6 message on pilot startup

Added by John Weigand over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
High
Assignee:
Parag Mhashilkar
Category:
Integration with Condor
Target version:
Start date:
07/06/2012
Due date:
% Done:

0%

Estimated time:
First Occurred:
Occurs In:
Stakeholders:
Duration:

Description

While testing v2.6.rc2 using Condor 7.7.6, I was seeing this message
in stderr of the pilot:

Starting monitoring condor at Fri Jul 6 11:03:07 CDT 2012 (1341590587)
/usr/local/osg-ce/OSG.DIRS/wn_tmp/glide_A13667/main/condor/sbin/condor_master:
/usr/local/osg-wn-client/globus/lib/libglobus_gssapi_gsi_gcc64dbg.so.0:
no version information available
(required by /usr/local/osg-ce/OSG.DIRS/wn_tmp/glide_A13667/main/condor/sbin/../lib/libcondor_utils_7_7_6.so)

This message does not appear when using Condor 7.6.6.

Not knowing what new "feature" this might be, I thought I should document it.

It does not appear to affect the basic (with emphasis on basic) functioning
of glideinWMS.

John Weigand

History

#1 Updated by Parag Mhashilkar over 8 years ago

Starting 7.7.x at some point, condor started shipping tarballs with dynamically linked libraries. I need to look into this.

#2 Updated by Derek Weitzel over 8 years ago

Hi Parag,

You are correct about the dynamic libraries. But I thought you had code for that in commit:737a8f6e in source:creation/lib/cgWCreate.py. (I largely copied it for the campus factory, thank you.)

The code is working in the campus factory, if that counts for anything. We're running brand new 7.9 branch for campus factory.

-Derek

#3 Updated by Parag Mhashilkar over 8 years ago

Yes the code is there in glideinwms and seems like it is doing the right thing too. John and I spent some time to understand the issue. Interesting thing is, condor_master is looking for libs that are in osg's wn rather than the libs that glidein bought with it.

/usr/local/osg-ce/OSG.DIRS/wn_tmp/glide_A13667/main/condor/sbin/condor_master: 
/usr/local/osg-wn-client/globus/lib/libglobus_gssapi_gsi_gcc64dbg.so.0: 

From my understanding, condor performs a hard library path search pattern. It always looks for libs in CONDOR_LOCATION/lib/condor before moving out to env or system areas. So what we see above should not be happening.

So far glideins still work except for the message you see in the log. But that could very well be because the osg-wn-client has good libs.

Let me see if there is any config/env variable that we need to set or if I can reproduce this issue with different versions of condor.

#4 Updated by Derek Weitzel over 8 years ago

fwiw, the campus factory sets LD_LIBRARY_PATH on the glidein to point to the libraries that where untarred.

#5 Updated by Parag Mhashilkar over 8 years ago

  • Status changed from New to Assigned
  • Assignee set to Parag Mhashilkar
  • Priority changed from Normal to High
  • Target version set to v2_6

Setting up LD_LIBRARY_PATH=$CONDOR_DIR/lib:$CONDOR_DIR/lib/condor:$LD_LIBRARY_PATH fixes this issue.

#6 Updated by Derek Weitzel over 8 years ago

Since 8.1 has already been released, which includes dynamic libraries. Does this mean that glideinwms factory does not work with the current stable Condor version?

#7 Updated by Parag Mhashilkar over 8 years ago

If I rephrase your question to "will factory always reliably work with glideins using condor with shared libraries", the answer is no. That's because now glideins become dependent on quality/compatibility of libraries installed by osg. Also even if you see the error messages, condor startd still fires up, reports to the user collector, accepts jobs and runs. Still I am not comfortable that glidein is not using intended libraries.

If the LD_LIBRARY_PATH is set, factory should work with glidein using new condor. I thought you are setting the LD_LIBRARY_PATH, if so you should be covered. Have a look at one of the glidein's output to see if you see the error messages.

I am going to check with the condor folks. From what was said during condor week this should not happening.

#8 Updated by Parag Mhashilkar over 8 years ago

  • Status changed from Assigned to Resolved

Talked to Jaime and he confirmed that condor will look for shared scripts in LD_LIBRARY_PATH then in RELEASE_DIR/lib and RELEASE_DIR/lib/condor and then in system areas. So fixing LD_LIBRARY_PATH should cover us.
branch_v2plus: commit:771cb8b
master: commit:4fa8d7d

#9 Updated by John Weigand over 8 years ago

Tested with all 3 rc3 tarballs using
Condor 7.6.6
Condor 7.7.6
Condor 7.8.0

This issue appears fixed.

John Weigand

#10 Updated by Parag Mhashilkar over 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF