Bug 487030 - no java universe (broken classpath)
no java universe (broken classpath)
Product: Fedora
Classification: Fedora
Component: condor (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Matthew Farrellee
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-02-23 13:43 EST by Dimitri Maziuk
Modified: 2009-02-24 15:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-23 20:00:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dimitri Maziuk 2009-02-23 13:43:44 EST
Description of problem:

condor_status -java produces no output

Version-Release number of selected component (if applicable):


Additional info:

StarterLog:2/23 13:36:45 JavaDetect: failure status 256 when executing /usr/bin/java -classpath /usr/lib:/usr/lib/scimark2lib.jar:. -Xmx1906M CondorJavaInfo old 2

scimark2lib.jar is in /usr/share/condor, not in /usr/lib where classpath above is looking for it.
Comment 1 Matthew Farrellee 2009-02-23 18:24:38 EST
$ rpm -q condor

$ condor_config_val -v JAVA_CLASSPATH_DEFAULT
JAVA_CLASSPATH_DEFAULT: /usr/share/condor /usr/share/condor/scimark2lib.jar .
  Defined in '/etc/condor/condor_config', line 1670.

$ ls -al /usr/share/condor/scimark2lib.jar
-rwxr-xr-x 1 root root 13756 2009-01-14 23:06 /usr/share/condor/scimark2lib.jar*

Is it possible that you modified /etc/condor/condor_config and now there's a condor_config.rpmnew that has the proper config for JAVA_CLASSPATH_DEFAULT?

If so, you should take your changes to /etc/condor/condor_config and put them in the condor_config.local file. Then replace /etc/condor/condor_config with the rpmnew. Generally keeping your changes in the condor_config.local and leaving the condor_config in /etc so that the package can update it as things change.
Comment 2 Dimitri Maziuk 2009-02-23 19:07:57 EST
You're right, sorry about that.

The problem is that in a large pool it's much easier to keep settings common to the pool in the central config file on an nfs share and use condor_config.local for settings local to the machine.

As opposed to distribution-default settings in central config file and settings local to the pool in local config file.

These include most of Part 1, almost all of Part 2 and large chunk of Part 3, whereas the only part that's really local is the list of daemons and start/preempt/suspend settings. I.e. my condor_config.local is 10 lines. Things like uid/fs domain, flocking and access list, pool name, admin e-mail etc. really belong in pool-global config file -- otherwise I have to somehow rsync them out to all the nodes while somehow not overwriting node-local settings at the same time.

One possible workaround is to use 2 local config files: "pool-global" and "really local". I might try that some day.
Comment 3 Matthew Farrellee 2009-02-23 20:00:53 EST
You can use the command generated config file trick (see of UW's 7.2.1 manual).

Basically, you leave /etc/condor/condor_config alone, and in your condor_config.local add:

  LOCAL_CONFIG_FILE = /bin/cat /nfs/condor_config/global /nfs/condor_config/$(FULL_HOSTNAME)|

 (The key is the | at the end of the line)

You put your global stuff in the obvious place and your local changes in a file with the appropriate name.

The immediate downside is you need a $(FULL_HOSTNAME) file for each node, but you can get around that by exec'ing your own script instead of /bin/cat. If you're worried about hammering NFS you can be arbitrarily clever in your script.
Comment 4 Dimitri Maziuk 2009-02-24 15:55:55 EST
Actually, putting
  LOCAL_CONFIG_FILE = /opt/condor/condor_config $(LOCAL_CONFIG_FILE)
in condor_config.local works, too. The only (minor) complaint I have is that with LOCAL_DIR defined as $(TILDE) I have to set condor user's home directory to /var/lib/condor in LDAP -- and /var/lib/condor doesn't exist on half the computers here. That and selinux whines about some already defined context.

Note You need to log in before you can comment on or make changes to this bug.