Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!uunet!shelby!portia.stanford.edu!elaine24.stanford.edu!dhinds
From: dhinds@elaine24.stanford.edu (David Hinds)
Newsgroups: comp.sys.sgi
Subject: Re: batch control
Message-ID: <1991Feb5.171530.11078@portia.Stanford.EDU>
Date: 5 Feb 91 17:15:30 GMT
References: <9102031532.AA15085@poly1.nist.gov> <1991Feb4.191058.1353@urz.unibas.ch>
Sender: news@portia.Stanford.EDU (Mr News)
Organization: Stanford University - AIR
Lines: 28

In article <1991Feb4.191058.1353@urz.unibas.ch> doelz@urz.unibas.ch writes:
>In article <9102031532.AA15085@poly1.nist.gov>, rbriber@POLY1.NIST.GOV writes:
>
>Regardles of the mechanism you used to push it to the background, you can send
>kill -STOP tp the pid of interest and kill -CONT to continue again. 
>If its not your process, you must be root. 
>Dont forget to start the process with nohup(1) if you dont use nqs, otherwise 
>it might die if you close the window. 
>
>> that started a given job the only communication you can have with that job
>> (from another session) is to kill it.  We talked to the hotline about being
>> able to temporarily stop and then restart the job from another window
>> and then restart it (sort of like ^z and then %% from the parent window) but
>> it doesn't seem possible.  We have a 4D80GT running 3.3.1.
>> 
    There is also an easy way out.  It seems that if a process's parent id
is 1 (because its parent has terminated), then it will not accept kill -STOP
and kill -CONT from the same user.  But, if you run your batch job via a
shell script, you will lose job control on the script when you log off, but
you will still be able to use STOP/CONT on your batch job, because its
immediate parent (the script) is still around.  All our users have some
sort of script to start a batch job for this reason.  Mine does stuff like
create a scratch directory for temporary links to data files, save standard
output and standard error to unique-named files, and sends me mail with
the error output when the job finishes.

 -David Hinds
  dhinds@cb-iris.stanford.edu