[GE users] No job status, but process still runs

Reuti reuti at staff.uni-marburg.de
Mon Jul 9 19:54:09 BST 2007


Am 09.07.2007 um 20:26 schrieb Daniel Templeton:

> Not that I know of.  In the past, when I've tried to get around an  
> issue with a daemonizing executable, I've written a wrapper script  
> that knew how to tell when the job was really done.

I don't know about this software "calibre64", but sometimes there are  
options available, which will prevent the forking.

-- Reuti

> Daniel
>
> Pat Cable wrote:
>> I figured that was the case. Any way to make it hang on?
>>
>> // Patrick Cable II
>> // LLCad System Administrator Co-Op
>> // MIT Lincoln Laboratory - F-378
>> // 781 981 5996 - cable at ll.mit.edu
>>
>>
>>
>> Daniel Templeton wrote:
>>> The reason is that your original executable exited.  The shepherd  
>>> waits for its child process to exit.  Once that happens, the job  
>>> is done from its perspective.  I think, though, that the orphaned  
>>> child processes will still have their resource usage added to the  
>>> job's accounting record.
>>>
>>> Daniel
>>>
>>> Pat Cable wrote:
>>>> Hi All,
>>>> I'm submitting a job to my queue (on SGE 6.1) like so:
>>>>
>>>>       qsub -q rhel4_16g.q $MGC_HOME/bin/rcalibre /home/user/ 
>>>> sgecalibre 1 MGC_HOME $MGC_HOME -mtflex $CALIBRE_REMOTE_CONNECTION
>>>>
>>>> This calls the rcalibre script, which sets an environment, and  
>>>> executes this:
>>>>       exec $MGC_HOME/bin/calibre -64 $*
>>>>
>>>> From there, the calibre tool invokes the correct binary for the  
>>>> platform selected, in this case, $MGC_HOME/pkgs/ivt/bin/calibre64
>>>>
>>>> Once that command is executed there is no longer an active job  
>>>> appearing in qstat - but the process is running on the proper  
>>>> machine. Why is this? Does it have to do with the fact that  
>>>> calibre64 is the child process of a child process?
>>>>
>>>> // Patrick Cable II
>>>> // LLCad System Administrator Co-Op
>>>> // MIT Lincoln Laboratory - F-378
>>>> // 781 981 5996 - cable at ll.mit.edu
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>>>> For additional commands, e-mail: users- 
>>>> help at gridengine.sunsource.net
>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net

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