Hi,

Am 28.01.2014 um 00:45 schrieb Txema Heredia:

> El 27/01/14 17:50, Reuti escribió:

>> Am 27.01.2014 um 17:26 schrieb Txema Heredia:
>> 
>>> I have been trying to use modulefiles from my compute nodes with no avail.
>>> 
>>> When a job starts, the modulecmd command is in the path, but the module 
>>> function is nowhere to be found. I have tried to add calls to 
>>> /etc/profile.d/modules.sh in both /etc/bashrc and ~/.bashrc, and even 
>>> setting the queue shell to "/bin/bash -l" with no luck (it is not a valid 
>>> shell). The only mens to have access to the "module" function is either to 
>>> add ". /etc/profile.d/modules.sh"
>> This could also be done in a "starter_method" of the queue which calls the 
>> real script:
>> 
>> #!/bin/bash
>> . /etc/profile.d/modules.sh
>> exec "${@}"
>> 
>> 
>>> at the beginning of my job script, or either log into the compute node in 
>>> an interactive session and there softstop and restart the sge_execd daemon.
>>> 
>>> What am I missing? How can I have the module function available in my jobs?
>> Any of the profiles are only sourced in case of "shell_start_mode 
>> posix_compliant" in the queue definition and listing bash in `qconf -mconf` 
>> "login_shells".
>> 
>> The module command is a function, which needs to be defined. For serial jobs 
>> it should work to define the function in the submitting session, export the 
>> function and use `qsub -v module ...`.
>> 
>> -- Reuti
> Oh, gosh!
> 
> After 3 hours testing and writing a 3-pages email, I just understood the last 
> part of your email. I realized that I had bash defined as the queue shell, 
> but not as a login_shell in the global configuration. Now modules simply 
> work, without using "bash -l" nor sourcing the modules.sh file, etc., and 
> with no need of the starter_method.
> 
> Thank you very much!
> 
> 
> PS: Even though I finally didn't need the starter_method script, I found it a 
> very interesting concept. Do you have any suggestions (or cool tricks) about 
> what to do with it?

In case you need to define any specific environment variables it could be put 
there. Also any prolog can be run therein, as long as it's sufficient to run it 
under the executing user. This might be useful, as you can't have a global and 
a queue prolog at the same time (only the queue prolog would be executed in 
that case).

-- Reuti


_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users

Reply via email to