Here are a couple things you can do to examine the output of individual jobs on the execute machine to test that the output is being transferred back appropriately:
1) Wrap a job in a shell script that copies everything in the execute directory to some other location after the real program exits. Then, you can examine those files after the job completes.
2) While the job is running, run condor_ssh_to_job. You will get a terminal session on the execute machine in the execute directory of the job. You can examine the files there interactively. Once the job finishes and you exit from the terminal session, the output files will be transferred back as normal and the job will be marked as completed.
-- Jaime Frey
Jaime Frey:
Thank you.
I want to just make sure that whatever output I am getting is really what is present on execute machine. Otherwise, there is no specific reason.
With regards, Harshad Prajapati On Tue, Feb 19, 2013 at 11:20 PM, Jaime Frey <jfrey@xxxxxxxxxxx> wrote:
On Feb 14, 2013, at 5:37 AM, Harshad Prajapati < harshad.b.prajapati@xxxxxxxxx> wrote:
> My question is related to submitting a job to condor using condor-g submission.
> I want to see where transferred executable and input files are stored on execute machine for job submitted using condor-g. Similarly, what about output file?
> Moreover, I want to keep those files on execute machines, what configuration do I need to do?
> Do I need to configure gsi-gatekeeper of globus or Startd of condor?
On the gatekeeper machine, Globus GRAM keeps job-related files in directories under the user's home directory. These directories are deleted when the GRAM client (e.g. Condor-G) tells it to do so.
Why do you want to keep these files on the execute machine after they've been transferred back to the job submitter?
Thanks and regards, Jaime Frey UW-Madison HTCondor Project
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}