[torqueusers] torque question

Lennart Karlsson Lennart.Karlsson at nsc.liu.se
Mon Apr 24 06:46:37 MDT 2006


Marc,

You wrote:
> I  am having some trouble with the use of torque. I have a torque 
> server+sched installed on our 60 node cluster. It is running very well 
> and I have no problem for the normal use.
> However, I need to execute some very short jobs on some queues in an 
> interactive way. I have checked the -I option which basically gives me a 
> shell in the asked node. This shell waits for the logout and appears in 
> the queue as a normal job. I think this is the expected behaviour. 
> However I would like to pass some options to the qsub -I order, in such 
> a way that it logs out automatically after executing them and returns 
> control of the initial shell afterwards. Such option could be the name 
> of a script to be executed or even simpler orders. Is that possible wiht 
> the "-I" option, or should I use some other option? I have checked the 
> man pages and found nothing that suits.


I am not exactly sure about what you want, but I assume that you want
to submit a short job on your submit host in such a way, that you can
continue to write commands in your shell on the submit host as soon as
the job has finished and not before?

As far as I know there is no such option to 'qsub'.

In August 2005, on this list, Mathieu Oudart asked for a "foreground
mode" to 'qsub' and I answered:
> To get your "foreground mode" I propose that you implement
> a simple "qwait" command that waits for any job that you
> give as a parameter to it.
> 
> E.g. if you want to run a job A, rename its output directory
> and run a job B, you could make a script like this:
>
>         qsub A > A.jobname
>         qwait `cat A.jobname`
>         mv A.results B.input
>         qsub B > B.jobname
>         qwait `cat B.jobname`
>
> It is the same way you construct depend chains, but allowing
> other types of actions between.
> 
> The qwait command could easily be constructed as a script that
> goes in a loop, mostly sleeping and now and then checking for completion
> by using the "qstat" command.
> 
> I prefer this method compared to adding a waiting option to "qsub", because a
> waiting option might make a system user believe that she/he could
> abort the batch job by hitting a control-C on her/his keyboard, the way it
> works with interactive jobs and the "qsub -I" command.

If you implement such a 'qwait' command, you can use it to wait for
the completion of short non-interactive jobs, before continuing working
in your shell.

Another approach to the problem is to use e.g. the excellent 'expect' tool,
letting 'expect' start an interactive 'qsub' and send your commands to
it. Here is a small example of a very simple such 'expect' script:

> #! /usr/bin/expect -f
> 
> # Submit interactive job
> spawn qsub -I -l walltime=1:00:00,nodes=1
>
> # Give job some commands (assuming that type-ahead is working)
> send "date > tempdatefile\r"
> send "sleep 60\r"
> send "date >> tempdatefile\r"
> send "exit\r"
> 
> # Wait for qsub exit
> wait

to give you an idea about this way of running interactive commands in batch.

-- Lennart Karlsson <Lennart.Karlsson at nsc.liu.se>
   National Supercomputer Centre in Linkoping, Sweden
   http://www.nsc.liu.se




More information about the torqueusers mailing list