Hi,
Am 17.12.2016 um 03:43 schrieb Peng Yu:
> Hi, I want to write the output file to the machine in which the job
> was submitted. It sounds like this is not possible with SGE. (see the
> example below.) Is it the case?
It's not directly a "behavior"/"missing feature" of GridEngine, but how your
cluster is set up. The job running on a node, can write to any location the
operating system can reach. Besides the local /scratch resp. /tmp it's often
the shared /home directory. If you wan't to write to the unshared /tmp of the
submission host, then it would be necessary to share it and mount it on the
exechost, so that the operating system has access to it. The advantage of this
etup is, that the output files can be written live, i.e. you can `tail` them
during execution. Other queuing systems like Torque copy the output/error files
only after the job to their final destination. I never saw a set up where they
were copied to any other location the somewhere in a shared /home. So I even
can't say, whether Torque as example of another queuing system would support
such a kind of file staging.
> $ cat task1.sh
> #!/usr/bin/env bash
> #$ -N task1
> #$ -pe pe1 1
Unless you want to use a feature of the parallel environment to make any
additional setups, it's not necessary to use a PE for a serial job.
> #$ -V
I judge -V often as unsafe. You make an adjustment to the environment on the
command line and a couple of days later your submitted job starts and crashes
and one has no clue why. And a resubmitted job in a fresh shell suddenly works
as expected. On the other hand the variant "-v foobar=baz" is completely fine
IMO.
> #$ -j yes
> sleep 1
> echo
> echo -ne "$HOSTNAME\ttask1\t"
> date
> $ cat main.sh
> #!/usr/bin/env bash
> # vim: set noexpandtab tabstop=2:
>
> tmpdir=/tmp/qsub
This is the /tmp/qsub is created on the submission host.
> mkdir -p "$tmpdir"
> qsub -o $HOSTNAME:"$tmpdir"/out.task1.o < task1.sh
The syntax of "-o" is meant in a different way: if the job is running on
$HOSTNAME, then use the path $tmpdir"/out.task1.o on the $HOSTNAME. Hence, if
you have several different versions of machines and different flavors OS
(Linux, OS X, AIX,…), the on each of the machines the path could be different
(and you can use more than one "-o" option in the submission, so the job will
behave in the correct way, wherever it is scheduled to). Looks like this
feature isn't used often, as the output of `qstat -j <job_id>` for such a
setting seems broken and was never fixed (ok, it's only cosmetic).
> echo "$tmpdir"
> $ ./main.sh
> Your job 7454 ("task1") has been submitted
> /tmp/qsub
> $ qstat -j 7454 |grep error
> error reason 1: 12/16/2016 20:38:57 [10006:17612]: error:
> can't open output file "/tmp/qsub/out.task1.o": No such file or
> directory
During execution it looks on the exechost for this paths.
Is the /home shared? Could you create a directory ~/myoutput there? My users
prefer to get the output of their jobs in the same directory as the associated
input file, and output of the GridEngine itself we route to a directory ~/err
in each user's home directory. Like:
#!/bin/sh
#$ -o ~/err
#$ -e ~/err
#$ -cwd
my_executable < my_input > my_output
-- Reuti
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
