[GE users] Configuration of the exit of stdout/stderr

Daniel Templeton Dan.Templeton at Sun.COM
Fri Jun 1 16:09:38 BST 2007


    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

Esteban,

The delegated_file_staging attribute is only used for DRMAA.  The DRMAA 
spec says that file staging is optional, so that setting tells DRMAA 
whether it has been configured for the cluster or not.  The only effect 
setting it to TRUE has is making the file staging functionality 
available from DRMAA.

The main piece of the delegating file staging story, though, is the 
$fs_*_path pseudo-variables that you can use in calling your 
prolog/epilog script.  Those rely on the PN_file_staging path of the 
path elements in the job structure.  The only place where 
PN_file_staging is set is in DRMAA.  If you're not using DRMAA, the file 
staging pseudo-variables will always be empty.

You should file and RFE for making the file staging hooks available from 
the command-line utilities.

Daniel

Esteban Freire Garcia wrote:
> Hi Reuti,
>
>     I?m Sorry to take so much in answering you, but I was doing tests with
> the epilog. I take a time in realizing that the script was not working
> because not it catch of the main node but rather it catch of the node in the
> one the job is executed, and therefore in the execution node the epilog
> script must be in the route that we configure in the qconf -mconf. Once I
> have this solved, the script continues without working (it?s to say, it
> continues without copy the files .e and .o), and this is because the
> variables as $fs_stdout_host..that catches the script for know the routes of
> the files .e and .o are empty. I was looking in google and I found "File
> staging is currently implemented  only  via  the  DRMAA interface", so my
> question is, Are there any form that these variables work with a normal
> qsub?, for examples, adding some parameter to qsub. That would be great!!
>
> Thank you very much,
> Esteban
>
>   
>> Hi,
>>
>> Am 21.05.2007 um 14:48 schrieb Esteban Freire:
>>
>>     
>>>    I need to know where I could configure for that the files .e
>>> and .o that are  generates when the job enter in execution, copy
>>> them in the directory of the user where the job is sent, because at
>>> the moment these archives are in the directory of the user but of
>>> the machine where they have executed. And I do not see where to
>>> change this.
>>>    Somebody could help me, please?
>>>       
>> often the ~ of the users is shared via NFS with all nodes, so
>> the .o/.e files will be visible in real-time somewhere in the
>> directory of the users. Otherwise you will have to setup to copy them
>> back to their ~, as this is not directly a built-in function. Maybe
>> an epilog would do in your case:
>>
>> http://gridengine.sunsource.net/howto/filestaging/filestaging6.html
>>
>> HTH - Reuti
>>
>> ---------------------------------------------------------------------
>> 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