[GE users] qrsh & stderr/qtdout file

Kirk Patton kpatton at transmeta.com
Mon Mar 29 18:14:48 BST 2004


On Mon, Mar 29, 2004 at 06:58:35PM +0200, Andy Schwierskott wrote:
> 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?

> 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
> 

-- 
Kirk Patton
Unix Administrator
Transmeta Inc.
Tel. 408 919-3055

---------------------------------------------------------------------
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