[GE users] qrsh & stderr/qtdout file

Andy Schwierskott andy.schwierskott at sun.com
Tue Mar 30 10:02:25 BST 2004


Kirk,

> > since the fix is not done yet (redirection to /dev/null) you need to folow
> > the directions in the "WORKAROUND" section where an "epilog" scripts deletes
> > the files $SGE_STDERR_PATH and $SGE_STDOUT_PATH (which are NOT set for
> > interactive jobs. There
>
> I can follow the workaround, but for directories that are not writable, the
> jobs fails to start at all because SGE is not able the created the unwanted
> o.id and e.id files.  If there is not workaround for that, that is o.k, I
> just need to make note of it in case one of my users asks. So, for directories
> that the user lack write permission, I surmize there is currently no way to
> prevent SGE from trying to write the files?

I've overseen the "-cwd" case. For jobs started with the -cwd option the
stdout/err files are created in the submit directory. This makes them
failing.

I'll change Issue #368. I'll give it a higher priority because the job
failure problem makes it indeed a non-workaroundable (does this workd
exist?) problem. I'm also updating the description.

Andy

> > This means that either by checking the env variable "JOB_SCRIPT" and/or by
> > checking for the attribute "script_file" in $SGE_JOB_SPOOL_DIR/config the
> > epilog can detect whether or not to delete the job stderr/out files for
> > interactive jobs. You have certainly noticed that for interactive jobs the
> > fiels are always created in the user's home directory.
>
> That is not what I noted. The behavior I am seeing for qrsh jobs is that they try to
> write to the current working directory even though I specify a different location in
> the sge_request file.
>
> Thanks,
> Kirk
> >
> >
> > -------------------------------------------
> > #!/bin/sh
> > # sample epilog script to delete stdout/err files for interactive jobs
> >
> > case $JOB_SCRIPT in
> >   QRSH|INTERACTIVE|QLOGIN|QRSH|QRLOGIN)
> >      echo rm -f $HOME/$JOB_NAME.o$JOB_ID
> >      echo rm -f $HOME/$JOB_NAME.e$JOB_ID
> >      ;;
> > esac
> > exit 0
> > -------------------------------------------
> >
> >
> > Andy
> >
> > On Mon, 29 Mar 2004, Kirk Patton wrote:
> >
> > > Hello,
> > >
> > > I am working with qrsh for interactive jobs and I have noticed that
> > > the stderr and stdout files are being created in the current working
> > > directory. If the user does not have write access to that directory,
> > > the session fails to start.
> > >
> > > I looked throught the archives and found a reference to bug #368. I am
> > > using generic PROLOG/EPILOG scripts so that users can specify thier own
> > > at the time of submission.
> > >
> > > I changed the default path for the stderr/stdout files from $HOME
> > > to /dev/null in the sge_request file, but I am still getting the
> > > error. I verified that regular qsub submission do not produce any
> > > files now, but qrsh still creates files of 0 bytes in length.
> > >
> > > Does anyone have any idea how to turn this off for qrsh?
> > >
> > > Thanks,
> > > Kirk
> > >
> > > BUG 368
> > > >DESCRIPTION:
> > > >Interactive jobs (i.e. qrsh, qsh, qlogin) leave
> > > >behind output/error files like normal qsub type
> > > >jobs if prolog/epilog procedures are run for these
> > > >jobs. Usually these files are not needed, but
> > > >there is no means to have these jobs run with
> > > >prolog/epilog without getting these files created.
> > > >
> > > >WORKAROUND:
> > > >An prolog/epilog procedure which is run also for
> > > >interactive jobs might remove it's own
> > > >output/error file explicitly. The path of these
> > > >files is known to these procedures
> > > >(SGE_STDERR_PATH and SGE_STDOUT_PATH env vars).
> > > >
> > > >HOWTOFIX:
> > > >For interactive jobs (i.e. qrsh, qsh, qlogin) the
> > > >default setting of -e/-o/-y must cause /dev/null
> > > >be used for output/error files. To retain the
> > > >means to get diagnosis information about
> > > >prolog/epilog runs the -e/-o/-y submit options
> > > >must be usable also for these jobs.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list