[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] user_job_wrapper and class ads
- Date: Tue, 27 Oct 2009 10:16:36 -0500
- From: Dan Bradley <dan@xxxxxxxxxxxx>
- Subject: Re: [Condor-users] user_job_wrapper and class ads
In Condor 7.4.0, the job ClassAd will be available as a file (named
.job.ad) in the job's scratch area on the worker node.
In Condor 7.2, the best mechanism that I can think of is to pass the
information about the job in the job's environment. In your case, this
does involve duplication, though I suppose you could do things like this:
In the submit file:
environment = RequiresWholeMachine=true
In the submit-side config file:
RequiresWholeMachine = regexp("RequiresWholeMachine=true",MY.Environment)
SUBMIT_EXPRS = $(SUBMIT_EXPRS) RequiresWholeMachine
So the user only has to define RequiresWholeMachine once, in the
environment, and then the RequiresWholeMachine ClassAd attribute is
automatically injected for them as an expression that searches through
the environment for the environment variable of the same name. It's a
bit of a strange way to do things, but I think it should work.
Jonathan D. Proulx wrote:
is there any way for a user_job_wrapper script to see into the class
ad for the job it's executing?
I could make users set envirounment variables to get the info I need,
but they would also need to set the same things as class ad
attributes and duplication is bad.
specificly this goes along with my wholessystem scheduling issues.
submit files currently push "+RequiresWholeMachine = True" which has
many scheduling implications, for those same jobs I want a wrapper
that waits untill system load drops, but I do not want this to affect
I could also make the users wrap their own jobs, but that's still two
things (though arguably defferent enough to be meaningful as someone
may want all the processors in a system bu tnot need to be 100% sure
everything is quiet before starting to execute)
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
You can also unsubscribe by visiting
The archives can be found at: