[GE users] SGE questions

john.li at mindspeed.com john.li at mindspeed.com
Thu Mar 1 19:35:28 GMT 2007


Andreas.Haas at Sun.COM 
03/01/07 11:05 AM
Please respond to
users at gridengine.sunsource.net


To
users at gridengine.sunsource.net
cc

Subject
Re: [GE users] SGE questions






On Thu, 1 Mar 2007, john.li at mindspeed.com wrote:

> Yes, I tried this.   But it introduced another problem.   Here is my
> observation and could/should be
> verified by the developer,
>
> First of all, my umask is always set to 002.
>
> When using -b y  (or change sge_request as -b y) to submit a job, any
> files generated by
> the job will use umask 022.
>
> BUT, when I use -b n  to submit the same job, the file generated by the
> SAME job
> will use 002, (I assume it inherited my umask, somehow.)

John, here I'm not yet entirely clear as whether you actually changed the 
source or not. Did you make the tests here with an unchanged Grid Engine
or not?

This behavior is based on an unchanged verions, v6u8, which I'm using as 
my production.

I changed source files in v61beta for all my needs and evaluation.

>
> Based on my observation, I'd like to run all my jobs as a script, so 
that
> I have CORRECT
> umask.   Now, I run into this problem of not using $PATH to search for 
my
> script, which we
> don't have to worry when submitted to LSF.
>
> Anyway,  it seems umask issue will be addressed in v61.

Slowly ... that could be an overhasty conclusion. Until now the case is 
not yet clear at all. Note also this here is an open-source project 
mailing list. This means that you may not perceive my email as kind of a 
feature announcements mail.

I wish the umask issue could be resolved asap.  Currently, in my 
production
environment,(v6u8) my users have to setup cron jobs to change file 
permissions
since we have no control of it.  This may not be a big issue for people
who start with SGE, but it is just one more reason for LSF user to resist
the change.


> I still think it
> would be much
> easier for the users if he/she does have to specifying the full path to
> run a script,
> which we do at almost 100% of the time.

I understand having qsub to reject any path that is not a full path 
would be the ideal solution. Is that correct?

Yes, the ideal solution is to have SGE search the $PATH for the script,
just like when submitting a binary exectable.


Thanks,
Andreas

> Currently, I have -b y in sge_request and deal with the umask 
separately.
>
> Thanks very much...
>
>
>
>
>
> Andreas.Haas at Sun.COM
> 03/01/07 10:26 AM
> Please respond to
> users at gridengine.sunsource.net
>
>
> To
> users at gridengine.sunsource.net
> cc
>
> Subject
> Re: [GE users] SGE questions
>
>
>
>
>
>
> On Thu, 1 Mar 2007, Rayson Ho wrote:
>
>> On 3/1/07, john.li at mindspeed.com <john.li at mindspeed.com> wrote:
>>> There is no distinction betweeen a binary executable and a script. In
>
>>> LSF, I don't
>>> worry
>>> about it.  I submit either a binary or a script, as long as it is in 
my
>
>>> search path, LSF
>>> will have no problem of running it.
>>
>> Again, this behavior of LSF is not POSIX compliant. Other common batch
>> systems spool the job script.
>
> When the "-b y" option is used scripts are not transfered either.
> That means if "-b y" is put into cluster-wide sge_request(5) that
> would be the behaviour John wishes to see.
>
> Somehow I don't get the point ...
>
> Regards,
> Andreas
>
> ---------------------------------------------------------------------
> 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