On 12/01/2011 09:16 AM, Reuti wrote:
> Hi,
>
> Am 01.12.2011 um 14:31 schrieb Prentice Bisbal:
>
>>> <snip>
>>> I finally had some time to dig around on my systems, and here's what I
>> found. Some of this will be obvious to experienced RHEL admins/users,
>> but I'm just trying to be complete, and provide a full explanation for
>> future googlers:
>>
>> 1 ./etc/bashrc or /etc/profile will source the files in /etc/profile.d,
>> which includes modules.sh
>>
>> 2. /etc/profile.d/modules.sh will call /usr/share/Modules/init/$shell or
>> /usr/share/Modules/init/sh:
>>
>> $ more modules.sh
>> shell=`/bin/basename \`/bin/ps -p $$ -ocomm=\``
>> if [ -f /usr/share/Modules/init/$shell ]
>> then
>> . /usr/share/Modules/init/$shell
>> else
>> . /usr/share/Modules/init/sh
>> fi
>>
>> Since my shell is bash, /usr/share/Modules/init/bash is called.
>>
>> 3. Amongst other things, /usr/share/Modules/init/bash defines the
>> function module() and then exports it in the first two lines of code:
>>
>> module() { eval `/usr/bin/modulecmd bash $*`; }
>> export -f module
>>
>> As you can see, there is a closing bracet, which is missing from the SGE
>> environment. Looking at the output of the 'env' command, I can confirm
>> that the full definition of module (from opening brace to closing brace)
>> makes it to my normal interactive, non-SGE environment. It looks like
>> this in the output of env:
>>
>> module=() { eval `/usr/bin/modulecmd bash $*`
>> }
>>
>> Notice, however, that the semicolon in the original definition is now a
>> new-line command. Which makes sense, but it must be tripping SGE due to
>> the known bug with multi-line environment variables in SGE 6.2u5, which
>> is what I'm using, as Reuti pointed out.
>>
>> It looks like I could just remove the environment modules packages from
>> my systems, but I do plan on using them in the near future, so I need to
>> fix this. I didn't have modules installed when running RHEL 5, so that
>> explains why this error just popped up after the upgrade to RHEL 6. Will
>> upgrading to an SGE 6.2 update greater than 5 fix my problem? Is an
>> update after u5 even available now, post-Oracle?
> is this really only a multi line problem? I mean: then output of env shows
> something like:
>
> foobar=() { echo yes
> }
>
> but even if you make one line out of it (with an additional ";") it can't be
> defined this way AFAICS:
>
> $ foobar() { echo yes; }
> $ export -f foobar
>
> Putting all in one line throws an error, especially with an = in the way.
>
> ==
>
> The workaround could be: define it as usual, but in a starter method.
>
> #!/bin/sh
> foobar() { echo yes; }
> export -f foobar
> exec "$@"
>
> For cosmetic reasons I would then even suggest to remove all foobar()=
> definitions from the SGE created environment file.
>
> -- Reuti
I don't want to go redefining the module function unless I absolutely
have to, since it's defined in a file managed by my distro, and may get
overwritten by an update, and this seems to be an SGE error.
I just ran ran a test job, but did 'unset module' before submitting it,
and as expected the module went away.
On the gridscheduler list, Rayson suggested that I just download the
latest trunk of gridscheduler, compile qsub from that source, and use
that to replace the qsub from 6.2u5. I'm going to give that a try. I'll
report my results later. Hopefully before the end of the day.
--
Prentice
_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users
