[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [condor-users] last job submitted info



An alternate solution is to parse the output of the condor_submit job
from bash:

$ condor_submit name.sub
Submitting job(s).
Logging submit event(s).
5 job(s) submitted to cluster 3.

I use a regex to give me some semblance of protection from changes in format / spacing tabs etc. but I hope this format isn't changing anytime soon :¬)
Assumption is that - for example in this case the resulting jobs will be

3.0
3.1
3.2
3.3
3.4

An alternate approach is to ignore cluster id and work off your own unique ids - this is somwhat tricky for condor_prio which do not allow constraint expressions (very annoying) but all the other job management one work.
In C# (or reasonable language of your choice with a GUID generator - does unix have a command to create one?) this is trivial buy including a GUID in the submit command

condor_submit -a "UniqueClusterIdAttribute=\"<guid>\"" <file>

Then all the jobs in the cluster have this id - not easy to type or remember I admit but it you want to then manipulate with tools it's much easier (as is unique across different schedd's unlike cluster id)

Matt


> -----Original Message-----
> From: owner-condor-users@xxxxxxxxxxx
> [mailto:owner-condor-users@xxxxxxxxxxx]On Behalf Of Campbell Bradley L
> CRBE
> Sent: 27 May 2004 19:21
> To: 'condor-users@xxxxxxxxxxx'
> Subject: RE: [condor-users] last job submitted info
> 
> 
> I'm not sure if this is exactly what you are after, but here 
> is what I do.
> 
> (I'm running Condor on Windows.)
> I have a batch file (csub.bat)  that is simply a wrapper for 
> condor_submit.  The contents are simply:
> 	condor_submit %1
> The batch file takes this first command line argument and 
> ignores the rest.
> This allows me to execute the command like this:
> 	csub submitFileName ->csub.log
> This redirects the output of csub to the file csub.log.  (The 
> batch file is necessary
> because otherwise condor_submit tries to interpret the 
> ->csub.log as an argument
> for it and this causes an error.)
> 
> I then wrote a very short FORTRAN program call GetClusterID 
> that opens csub.log,
> gets the ID from the file, and writes an empty file  whose 
> name is _ClusterID_### where ### is the 
> cluster ID of the job just submitted.  This has been pretty helpful. 
> 
> This is something that I'm
> sure the condor folks could implement quite easily.  Maybe as 
> an option in the submit file:
> create_clusterID_file = true
> 
> Brad
> 
> -----Original Message-----
> From: Jaime Frey [mailto:jfrey@xxxxxxxxxxx]
> Sent: Thursday, May 27, 2004 1:30 PM
> To: 'condor-users@xxxxxxxxxxx'
> Subject: RE: [condor-users] last job submitted info
> 
> 
> On Thu, 27 May 2004, Kewley, J (John) wrote:
> 
> > > >     condor_history roy | tail -1
> > >
> > > Sorry, this answer isn't quite complete. That will tell you
> > > about the last
> > > job submitted and completed.
> >
> > Are you sure? Is not just the last job (or indeed subjob) 
> to complete?
> > Submission doesn't come into it.
> >
> > > You'll have to look at "condor_q roy"
> > > (submitting your user name, of course) to see what jobs have
> > > not completed.
> >
> > Again, this doesn't help if you have submitted a variety of 
> jobs with
> > different
> > requirements, some of whom have completed and some not. You 
> may have only
> > one job
> > in the queue, and it was submitted this morning, waiting 
> for an overnight
> > resource;
> > meanwhile a couple of hundred short jobs could have run 
> during the day.
> >
> > Does the following find the most recently submitted job by 
> user jk on the
> > current (submit) node, $CONDOR_SPOOL being the spool directory:
> >
> > cat ${CONDOR_SPOOL}/job_queue.log | grep -w User | grep jk 
> | tail -1 | cut
> > -d" " -f2 | cut -d. -f1
> 
> job_queue.log only contains information about jobs that are 
> still in the
> queue. Digging in there will get you the same information as running
> condor_q (i.e. you'll only see jobs that haven't completed 
> and left the
> queue yet).
> 
> Be careful about mucking around in job_queue.log. We make no 
> guarantees
> about not changing its format in the future. However, there 
> is a simple
> way to find out what cluster id the schedd will assign the 
> next job to be
> submitted:
> 
> grep '^103 0.0 ' ${CONDOR_SPOOL}/job_queue.log|tail -1|cut -d" " -f4
> 
> All jobs already submitted will have lower cluster ids.
> 
> +----------------------------------+---------------------------------+
> |            Jaime Frey            | I stayed up all night playing   |
> |        jfrey@xxxxxxxxxxx         | poker with tarot cards. I got a |
> |  http://www.cs.wisc.edu/~jfrey/  | full house and four people died.|
> +----------------------------------+---------------------------------+
> Condor Support Information:
> http://www.cs.wisc.edu/condor/condor-support/
> To Unsubscribe, send mail to majordomo@xxxxxxxxxxx with
> unsubscribe condor-users <your_email_address>
> Condor Support Information:
> http://www.cs.wisc.edu/condor/condor-support/
> To Unsubscribe, send mail to majordomo@xxxxxxxxxxx with
> unsubscribe condor-users <your_email_address>
> 
> 


*****************************************************************
Gloucester Research Limited believes the information 
provided herein is reliable. While every care has been 
taken to ensure accuracy, the information is furnished 
to the recipients with no warranty as to the completeness 
and accuracy of its contents and on condition that any 
errors or omissions shall not be made the basis for any 
claim, demand or cause for action.
*****************************************************************

Condor Support Information:
http://www.cs.wisc.edu/condor/condor-support/
To Unsubscribe, send mail to majordomo@xxxxxxxxxxx with
unsubscribe condor-users <your_email_address>